Compliance Gdpr Hipaa

Key Definitions:

• Personal Data: Any information relating to an identified or identifiable natural person (email, IP, location, even a photo).
• Processing: Any operation on personal data (collecting, storing, analyzing, deleting, transmitting).
• Data Controller: The entity deciding why and how data is processed (your company).
• Data Processor: The entity processing data on behalf of the controller (AWS, Stripe, email service). Must have a Data Processing Agreement (DPA).
• Data Subject: The individual whose data is processed (your user).

Step 2: Legal Basis for Processing

You must choose ONE legal basis before processing ANY data:

1. Consent (Article 6(1)(a)): User explicitly agrees. Must be informed, specific, unambiguous.

   • Bad: "By clicking submit, you consent to all processing." (Too vague)
   • Good: "I consent to receiving marketing emails every Tuesday." (Specific)
   • Withdrawal must be as easy as consent.

2. Contractual (Article 6(1)(b)): Processing is necessary to deliver a service the user contracted for.

   • Example: Storing billing address to ship an order.

3. Legal Obligation (Article 6(1)(c)): Law requires the processing.

   • Example: Storing transaction records for tax purposes (7 years).

4. Vital Interests (Article 6(1)(d)): Processing is necessary to protect someone's life.

   • Example: Hospital sharing medical records during an emergency.

5. Public Task (Article 6(1)(e)): Processing is necessary for a public authority's official function.

   • Example: Government agency processing welfare applications.

6. Legitimate Interests (Article 6(1)(f)): Your interests outweigh the individual's privacy rights (requires Balancing Test).

   • Example: Fraud detection. Test: Is the data processing necessary? Are there less intrusive alternatives? Would the data subject reasonably expect this?

Step 3: Data Protection Impact Assessment (DPIA)

Mandatory for high-risk processing (biometric data, large-scale profiling, automated decision-making affecting rights).

# DPIA: Real-time location tracking in delivery app

## 1. Processing Description
- Data: GPS coordinates, speed, geofence entry/exit
- Frequency: Every 10 seconds during delivery
- Duration: 8 hours/day for delivery drivers
- Storage: 90 days, then anonymized

## 2. Necessity & Proportionality
- **Necessity**: Route optimization, customer ETA, theft prevention
- **Alternative**: Collect location only at delivery start/end (less invasive)
- **Proportionality**: Driver consents (contractual necessity), benefits outweigh privacy intrusion

## 3. Risk Assessment
| Risk | Likelihood | Impact | Mitigation |
|------|---|---|---|
| Location data leaked | Medium | High (stalking, theft) | Encryption, access controls, employee training |
| Driver profiled for productivity | High | Medium (surveillance) | De-identification after 90 days |
| Tracking after shift ends | Medium | High (privacy violation) | Automatic location stop at shift end |

## 4. Mitigation Measures
1. Minimize data: Collect location every 30 seconds (not 10).
2. Pseudonymization: Replace driver name with ID in logs.
3. Encryption: AES-256 in transit and at rest.
4. Access control: Only route optimization team can access, not management.
5. Retention: Delete after 90 days automatically.
6. Transparency: Driver sees what's being collected and why.

## 5. Residual Risk Assessment
- **Acceptable?** Yes, with above measures.

Step 4: Consent Management

# Consent must be explicit, informed, specific, freely given

class ConsentRecord:
    def __init__(self, user_id, purpose, version):
        self.user_id = user_id
        self.purpose = purpose  # 'marketing', 'analytics', 'third_party_ads'
        self.version = version  # Version of consent form (for audit)
        self.given_at = datetime.utcnow()
        self.ip_address = request.remote_addr  # Proof of consent
        self.user_agent = request.headers['User-Agent']
        self.withdrawn_at = None

def withdraw_consent(user_id, purpose):
    consent = db.query('consents', user_id=user_id, purpose=purpose)
    consent.withdrawn_at = datetime.utcnow()

    # Upon withdrawal, stop processing immediately
    if purpose == 'marketing':
        email_service.unsubscribe(user_id)
    elif purpose == 'analytics':
        analytics.delete_user(user_id)

Critical: Pre-checked consent boxes violate GDPR. User must actively click/toggle consent.

Step 5: Data Subject Rights (GDPR Articles 12-22)

Right of Access (Article 15)

User can request all data you hold about them. You must respond within 30 days with:

• What data is collected.
• Why it's processed.
• Who it's shared with.
• How long it's retained.
• Recipient's email address.

@app.route('/api/gdpr/download', methods=['GET'])
def download_user_data():
    user_id = request.user_id
    data = {
        'profile': db.get_user(user_id),
        'orders': db.get_orders(user_id),
        'interactions': db.get_interactions(user_id),
        'consent_records': db.get_consents(user_id),
        'processing_purposes': ['account management', 'fraud detection']
    }
    return json_response(data), 200

Right to Rectification (Article 16)

User can correct inaccurate data. You must update within 30 days.

Right to Erasure ("Right to be Forgotten") (Article 17)

User can demand deletion under these conditions:

• Data is no longer necessary for the original purpose.
• User withdraws consent (and consent is your legal basis).
• User objects to processing (and no compelling legitimate interest exists).
• Data is processed illegally.
• Legal obligation requires erasure.

Exceptions (you can refuse):

• Legal obligation to keep (e.g., tax records for 7 years).
• Legitimate interests override (e.g., fraud prevention).
• Data is pseudonymized (no longer personal data).

@app.route('/api/gdpr/erase', methods=['DELETE'])
def erase_user():
    user_id = request.user_id

    # Check if erasure is permitted
    if has_pending_refund(user_id) or is_under_legal_hold(user_id):
        return {'error': 'Erasure blocked: pending refund'}, 409

    # Full erasure
    db.delete_user(user_id)  # Soft delete: mark as deleted, don't remove
    # Rationale: hard delete breaks referential integrity in orders, transactions
    storage.delete_user_files(user_id)
    analytics.delete_user_profile(user_id)

    # Notify 3rd party processors
    stripe.delete_customer(user_id)
    email_service.unsubscribe(user_id)

    log_audit_event('erasure', user_id, datetime.utcnow())
    return {'status': 'erased'}, 200

Soft Delete Approach (Recommended):

-- Keep record but mark as deleted
ALTER TABLE users ADD COLUMN deleted_at TIMESTAMP;

-- Never query deleted users
SELECT * FROM users WHERE deleted_at IS NULL;

-- After 7-year retention, hard delete
DELETE FROM users WHERE deleted_at < NOW() - INTERVAL '7 years';

Right to Restrict Processing (Article 18)

User can request you freeze their data (don't use it, but keep it).

def restrict_user_processing(user_id):
    user.processing_restricted = True
    # Stop all automated decision-making, analytics, etc.
    # But maintain data for potential future processing.

Right to Data Portability (Article 20)

User can request their data in a portable format (JSON, CSV) to move to a competitor.

@app.route('/api/gdpr/export', methods=['GET'])
def export_user_data():
    user_id = request.user_id
    data = db.get_all_user_data(user_id)
    return send_csv(data, filename=f'user_{user_id}_export.csv')

Right to Object (Article 21)

User can object to processing based on legitimate interests.

• You must then stop processing unless you have compelling reasons to continue.

Rights Related to Automated Decision-Making (Article 22)

Users have the right not to be subjected to automated decisions affecting their rights (denying a loan, firing, etc.) unless:

• The decision is necessary for contract performance.
• The decision is authorized by law.
• You obtained explicit consent.

If automated decision-making is used, provide:

• Explanation of the logic.
• Meaningful human review option.
• Right to object.

Step 6: Breach Notification (72-Hour Rule)

Article 33: If a breach of personal data occurs, you must notify the Data Protection Authority (DPA) within 72 hours.

def handle_data_breach(data_type, affected_users_count, breach_date):
    """
    Notify within 72 hours of discovering breach (not when it occurred).
    """
    notification = {
        'description': f'{affected_users_count} users\' {data_type} exposed',
        'date_of_breach': breach_date,
        'date_of_discovery': datetime.utcnow(),
        'likely_consequences': 'High risk of identity theft',
        'measures_taken': 'Accounts locked, password reset forced, notification email sent',
        'controller_contact': '[email protected]'
    }

    # Notify DPA immediately
    dpa = get_dpa_for_jurisdiction(user_jurisdiction)  # E.g., CNIL for France
    submit_breach_notification(dpa, notification)

    # Notify affected users (if high risk)
    for user_id in affected_users:
        send_email(user_id, 'Your data was exposed in a breach. Reset your password.')

Exception: Notify DPA UNLESS the breach is unlikely to cause harm (e.g., only internal employee emails, data already encrypted).

Step 7: Data Processing Agreement (DPA)

Article 28: Every processor you use (AWS, Stripe, email service) must sign a DPA.

# Data Processing Agreement (Stripe)

## 1. Scope
Stripe processes payment card data and transaction details on behalf of [Your Company].

## 2. Processing Details
- Data: Card tokens (masked), transaction amounts, IP addresses
- Purpose: Payment processing and fraud detection
- Duration: For the lifetime of the customer relationship
- Processor Location: USA, EU (data centers depend on region)

## 3. Security Measures
- Encryption: AES-256 at rest, TLS 1.2+ in transit
- Access Control: Limited staff, 2FA required
- Audits: SOC 2 Type II, PCI-DSS Level 1
- Sub-processors: [List of third parties Stripe uses]

## 4. Data Subject Rights
- Stripe must assist in fulfilling subject access requests
- Stripe must delete data upon instruction (within agreed timeframe)

## 5. Liability
- Stripe is liable for damages if it violates GDPR.

## 6. Term & Termination
- On termination, Stripe deletes all personal data unless law requires retention.

HIPAA (Health Insurance Portability and Accountability Act)

Applies to Covered Entities (healthcare providers, health plans, healthcare clearinghouses) and Business Associates (anyone processing Protected Health Information (PHI)).

Protected Health Information (PHI)

Any health information (explicit or implicit) that can identify an individual:

• Medical records, diagnoses, prescriptions.
• Billing records with health details.
• Genetic information.
• Even anonymized data can be re-identified if combined with other datasets.

Step 1: Business Associate Agreement (BAA)

If you process PHI, sign a BAA with the Covered Entity.

# Business Associate Agreement (EHR Vendor)

## 1. Permitted Uses
- Vendor processes patient medical records on behalf of [Hospital].
- Vendor may use PHI only for: Data storage, backup, maintenance.
- Vendor must NOT use PHI for marketing, secondary analysis, or sharing with third parties.

## 2. Security Requirements
- Minimum 256-bit encryption at rest.
- TLS 1.2+ for transmission.
- Multi-factor authentication for staff access.
- Annual security risk analysis.
- Incident response plan (notify within 24 hours).

## 3. Breach Notification
- Vendor notifies Hospital within 24 hours of discovering a breach.
- Hospital notifies affected patients within 60 days.

## 4. Subcontractors
- Vendor must require all subcontractors to sign BAA or DPA.
- Vendor remains liable for subcontractor violations.

## 5. Audit Rights
- Hospital reserves the right to audit vendor's security controls.

## 6. Termination
- Upon contract end, all PHI is securely destroyed or returned to Hospital.

Step 2: Encryption Standards (HIPAA Minimum)

Step 3: Access Controls

# HIPAA requires role-based access with minimum necessary principle

ROLES = {
    'doctor': ['read:own_patients', 'write:own_patients', 'order:tests'],
    'nurse': ['read:assigned_patients', 'write:vitals_only'],
    'billing': ['read:billing_only'],  # No access to diagnoses
    'admin': ['read:all', 'write:all']  # Rarely needed, logged heavily
}

def can_access(user_id, action, patient_id):
    user = db.get_user(user_id)

    # Minimum necessary check: Is the user actually treating this patient?
    if action.startswith('read:') and not is_treating(user_id, patient_id):
        log_access_denial(user_id, action, patient_id)
        return False

    # HIPAA Audit Log
    log_hipaa_access(
        user_id=user_id,
        action=action,
        patient_id=patient_id,
        ip_address=request.remote_addr,
        timestamp=datetime.utcnow()
    )

    return action in ROLES.get(user['role'], [])

Step 4: Audit Trails (Non-Repudiation)

HIPAA requires comprehensive audit logging of all PHI access.

# Schema for HIPAA audit logs
class AuditLog:
    id: int
    user_id: str
    action: str  # 'read', 'write', 'delete'
    resource_type: str  # 'patient_record', 'lab_result'
    resource_id: str  # patient ID, lab ID
    timestamp: datetime
    ip_address: str
    success: bool
    failure_reason: str (optional)
    change_details: dict (optional)  # If write/delete, what changed

# Audit logs must be:
# 1. Immutable: Write-once, read-many (WORM) storage
# 2. Retained: Minimum 6 years
# 3. Tamper-evident: Cryptographic hashing to detect changes
# 4. Reviewed: Quarterly for unauthorized access patterns

Step 5: Breach Notification (HIPAA)

Notify affected individuals within 60 days (faster than GDPR's 72 hours to authority).

def notify_breach(affected_count, data_type, breach_date):
    # 1. Notify individuals
    for patient_id in affected_list:
        send_breach_notification_letter(patient_id)

    # 2. Notify media (if 500+ individuals in same jurisdiction)
    if affected_count >= 500:
        notify_media()

    # 3. Notify HHS (Department of Health & Human Services)
    notify_hhs_breach_portal()

    # 4. Document in breach log
    log_breach_for_audit(affected_count, data_type, breach_date)

SOC 2 Type II (Trust Service Criteria)

Not a regulation, but a Trust Service certification. Demonstrates to customers that you have controls for:

1. Security: Systems protected against unauthorized access.
2. Availability: Systems available as promised.
3. Processing Integrity: Data processed accurately and completely.
4. Confidentiality: Sensitive data protected from unauthorized disclosure.
5. Privacy: Personal data collected per your stated privacy policy.

Audit: Annual assessment by independent auditor covering 6-12 month period.

# SOC 2 Type II Control Example: Encryption of Data at Rest

## Control Objective
All data at rest must be encrypted with AES-256 to prevent unauthorized disclosure.

## Control Activity
1. Database encryption enabled (AWS RDS encryption, Postgres pgcrypto).
2. Backup encryption enabled.
3. Key management: Keys rotated quarterly via AWS KMS.
4. Access restricted: Only application service account can decrypt.

## Testing Performed
- Auditor verified encryption settings in AWS console.
- Auditor verified encryption keys are not publicly exposed.
- Auditor tested that unencrypted data is not accessible.
- Auditor reviewed key rotation logs (3 rotations in audit period).

## Result
✓ **Operating Effectively**: Control operating as designed throughout audit period.

PCI-DSS (Payment Card Industry Data Security Standard)

Applies if you handle, transmit, or store credit card data.

SAQ (Self-Assessment Questionnaire) Types

• SAQ-A (Simplest): You use a fully hosted payment processor (Stripe, Square). You never see card numbers. ~40 questions.
• SAQ-A-EP: You redirect users to processor's payment page, handle a few bytes of data. ~100 questions.
• SAQ-D (Most Complex): You build your own payment system or store card data. ~330 questions + external penetration test required.

Minimum Requirements (All SAQs)

1. Firewall: All systems behind a firewall. No direct internet access to card data.
2. Encryption: All card data encrypted at rest (AES-256) and in transit (TLS 1.2+).
3. Access Control: Unique user ID for all system access. No shared accounts.
4. Auditing: Log all access to card data. Retain for 1 year.
5. Vulnerability Management: Patch OS and applications monthly.
6. Anti-virus: Required (though less common today).
7. Policy: Formal information security policy.

Tokenization (Recommended)

Instead of storing card numbers, store tokens:

# User enters card details on Stripe's hosted form
# Stripe returns a token: tok_visa_4242

# Your database stores: token, not card number
order.payment_token = 'tok_visa_4242'
db.save(order)

# Charge later
charge = stripe.Charge.create(
    amount=1000,
    currency='usd',
    source='tok_visa_4242'  # Use token, not card number
)

# Your servers never see card number = SAQ-A compliance

Privacy by Design (GDPR Article 25)

Principle: Build privacy into your system from day 1, not as an afterthought.

Privacy by Design Checklist

1. Data Minimization: Collect only what's necessary.

   • ❌ Collect: Name, Email, Phone, Address, Birthdate, Gender, Ethnicity, Religion
   • ✓ Collect: Name, Email (sufficient for account creation)

2. Pseudonymization: Replace identifiable data with IDs.

   • Instead of storing "John Smith, [email protected]", store "user:12345"
   • Analytics queries use user:12345, not names.

3. Purpose Limitation: Data collected for one purpose cannot be used for another (without new consent).

   • Collected for account management? Cannot use for marketing without consent.

4. Storage Limitation: Delete data when no longer needed.

   • Implement retention policies: Customer data deleted 1 year after account closure.
   • Backup data deleted 30 days after primary deletion.

5. Integrity & Confidentiality: Encrypt sensitive data, restrict access, maintain audit trails.

6. Accountability: Document all processing, maintain audit logs, demonstrate GDPR compliance.

# Privacy by Design Example: User Registration

# 1. Minimal collection (data minimization)
class UserSignup:
    email: str  # Necessary for authentication
    password: str  # Necessary for authentication
    # No: phone, address, gender, etc. unless required

# 2. Encryption at rest (confidentiality)
password_hash = argon2.hash(password)
email_encrypted = AES.encrypt(email, key=encryption_key)

# 3. Retention policy (storage limitation)
deletion_scheduled = now() + timedelta(days=365 * 7)  # 7-year legal hold

# 4. Audit trail (accountability)
log_account_creation(
    user_id=new_user.id,
    timestamp=now(),
    ip_address=request.remote_addr,
    consent_version='v2.0'
)

# 5. Purpose limitation
# Consent choices:
# - "Essential" (account management) - mandatory
# - "Marketing" (emails, newsletters) - optional
# - "Analytics" (usage patterns) - optional

Output Format

# 🔒 Regulatory Compliance & Privacy Architecture Review

## I. GDPR Compliance Assessment
- [ ] Data inventory created (all personal data types catalogued)
- [ ] Legal basis identified for each processing type
- [ ] DPIA completed for high-risk processing
- [ ] Consent mechanism implemented (explicit opt-in)
- [ ] Data Subject Rights workflows implemented (access, erasure, portability)
- [ ] Data Processing Agreements signed with all processors
- [ ] Breach notification process documented (72-hour DPA notification)

### Critical Gaps
1. [Gap 1]: Consent is pre-checked (violates GDPR Article 7)
   - **Fix**: Implement unchecked-by-default consent boxes

2. [Gap 2]: Marketing emails sent without opt-in consent
   - **Fix**: Implement double-opt-in (confirmation email required)

## II. HIPAA Compliance (if applicable)
- [ ] BAA signed with Covered Entity
- [ ] PHI encryption: AES-256 at rest, TLS 1.2+ in transit
- [ ] Access controls enforced (role-based, minimum necessary)
- [ ] Audit trails captured for all PHI access
- [ ] Breach notification plan (60-day patient notification)

## III. PCI-DSS Compliance
- **SAQ Type**: [A / A-EP / D]
- [ ] Tokenization implemented (card data never stored)
- [ ] Firewall enforced
- [ ] Encryption for data in transit and at rest
- [ ] Access logging (1-year retention)

## IV. Privacy by Design Assessment
- Data minimization: ✓ Only essential data collected
- Pseudonymization: ✓ User IDs used in analytics
- Purpose limitation: ✓ Consent per use case
- Retention policies: ✓ Auto-deletion after [X years]

## V. Recommendations
1. [Implement GDPR Right to Erasure workflow]
2. [Upgrade encryption to AES-256]
3. [Schedule annual SOC 2 Type II audit]

## VI. Skill Chaining
- Chain to `security-audit` for comprehensive threat assessment.
- Chain to `authentication-system` for PII handling in auth tokens.

Implementation Roadmap

1. Month 1: Data inventory, legal basis identification, DPIA.
2. Month 2: DPA signing, consent mechanism implementation.
3. Month 3: Data Subject Rights workflows (access, erasure, portability).
4. Month 4: Encryption hardening, audit trail implementation.
5. Month 5-6: Testing, external audit (SOC 2 / PCI-DSS if applicable).