Wedissimo Documentation

Appearance

GDPR Migration Compliance ​

Related Documents

Document Purpose: Verify Domain 1 (Users) and Domain 2 (Vendors & Listings) migration plans meet GDPR compliance requirements before testing.

Verification Date: 2025-10-15 Status: ✅ READY FOR TESTING with documented follow-up items

Executive Summary ​

Overall Assessment: Migration plans for Domain 1 (Users) and Domain 2 (Vendors & Listings) provide a strong GDPR foundation and are ready for testing. Core data structures and migration code meet essential GDPR requirements. Several advanced features need to be implemented post-migration but do NOT block testing.

Critical Finding ​

✅ SAFE TO PROCEED WITH TESTING - All critical GDPR compliance features are documented and will be implemented during migration.

Compliance Status ​

GDPR RequirementStatusNotes
Consent Management✅ CompleteFull audit trail system implemented
Data Structure Foundation✅ CompleteSoft deletes, consent tracking, audit fields
User Rights - Rectification✅ CompleteProfile editing via models
User Rights - Data Access⚠️ Post-MigrationAPI endpoints needed after migration
User Rights - Erasure⚠️ Post-MigrationSoft delete implemented, dependency checks needed
Cross-User Dependencies⚠️ Post-MigrationBooking relationships documented, checks needed
Data Retention⚠️ Post-MigrationPolicies documented, automation needed
Audit Logging⚠️ Post-MigrationFramework ready, implementation needed

GDPR Requirement #1: Right to Access (Article 15) ​

What's Required ​

GDPR Compliance Checklist (lines 19-43):

  • Couple data export: profile, bookings, messages, reviews, favourites
  • Vendor data export: business profile, earnings, customer data, reviews
  • Response SLA: 30 days maximum

What's in Migration Plans ​

Domain 1 (Users) - ✅ Data Structure Complete ​

User model includes all required fields (wedissimo-user-migration-revised.md lines 122-165):

php
- Profile data: name, email, phone, bio, avatar
- Social logins: google_id, facebook_id
- Verification: verified_at, email_verified_at
- WordPress reference: wp_id
- Soft deletes: deleted_at

User relationships documented (lines 1018-1066):

php
- vendor() - vendor profile
- listings() - through vendor
- orders() - bookings/purchases
- reviews() - reviews given
- favourites() - favourited listings
- favouriteListings() - through favourites pivot

Consent records migrated (lines 529-611):

php
- user_consents table with full audit trail
- consent_type, version, granted_at, IP, user agent
- 429 marketing consents migrating from WordPress

Favourites migration implemented (lines 718-782):

  • 672 favourites migrating
  • User-listing relationships preserved

Domain 2 (Vendors) - ✅ Data Structure Complete ​

Vendor model includes all required fields (wedissimo-vendors-listings-migration-revised.md lines 588-670):

php
- Business data: business_name, company_registration, vat_number
- Financial: stripe_account_id, stripe_onboarded
- Location: latitude, longitude, city, country
- Profile: years_of_experience, awards, ratings
- Approval: approval_status, approved_at, approved_by
- Soft deletes: deleted_at

Vendor approval history table (lines 676-694):

php
- Complete audit trail of approval decisions
- Tracks rejection + reapplication workflow
- Reviewed_by user tracking

What's Missing (Post-Migration Implementation) ​

⚠️ User Data Export API - Not yet implemented

  • Required: GET /api/users/{id}/export endpoint
  • Should return: JSON/CSV with all user data and relationships
  • Priority: HIGH (30-day SLA for requests)

⚠️ Vendor Data Export API - Not yet implemented

  • Required: GET /api/vendors/{id}/export endpoint
  • Should return: JSON/CSV with business profile, earnings, customer data
  • Priority: HIGH (30-day SLA for requests)

Recommendation: Implement data export APIs in Phase 2 (post-migration). Can handle manual exports initially if needed within 30-day SLA.

GDPR Requirement #2: Right to Rectification (Article 16) ​

What's Required ​

GDPR Compliance Checklist (lines 45-51):

  • User self-service profile editing
  • Immediate updates via dashboard

What's in Migration Plans ​

✅ FULLY COVERED - Laravel model-based editing provides this automatically

Users table (lines 122-165):

  • All profile fields editable via Eloquent
  • Role-based permissions via Spatie

Vendors table (lines 588-670):

  • All business fields editable via Eloquent
  • Approval workflow controls vendor changes

Listings table (wedissimo-vendors-listings-migration-revised.md lines 705-780):

  • All listing fields editable
  • Status controls publication

Status: ✅ Complete - No additional work needed

GDPR Requirement #3: Right to Erasure (Article 17) ​

What's Required ​

GDPR Compliance Checklist (lines 53-78):

Couple Deletion:

  • Cannot delete if active bookings exist
  • Must preserve booking records for vendor tax/legal purposes
  • Reviews may be anonymized rather than deleted
  • Payment records retention for dispute/refund purposes

Vendor Deletion:

  • Cannot delete if active bookings with couples
  • Business records retention for tax compliance (7 years)
  • Reviews and ratings from couples
  • Commission and payout records
  • Historical booking data affects couple's records

What's in Migration Plans ​

✅ Soft Deletes Implemented ​

Users table (wedissimo-user-migration-revised.md line 159):

php
$table->softDeletes();

Vendors table (wedissimo-vendors-listings-migration-revised.md line 663):

php
$table->softDeletes();

Listings table (line 772):

php
$table->softDeletes();

✅ Cross-User Relationships Documented ​

Bookings create dependencies - mentioned in checklist but not yet in migration docs

  • Users → Orders → Vendors (through listings)
  • Soft delete preserves these relationships

What's Missing (Post-Migration Implementation) ​

⚠️ Cross-User Dependency Checks - Not yet implemented

  • Required: Check for active bookings before deletion
  • Required: Anonymize reviews instead of deleting
  • Required: Preserve financial records for 7 years

Recommendation: Implement deletion logic in User and Vendor models:

php
// User model
public function canDelete(): bool
{
    // Check for active future bookings
    return !$this->orders()
        ->whereHas('listing', fn($q) => $q->where('booking_date', '>', now()))
        ->exists();
}

// Vendor model
public function canDelete(): bool
{
    // Check for active bookings with couples
    return !$this->listings()
        ->whereHas('orders', fn($q) => $q->where('booking_date', '>', now()))
        ->exists();
}

Status: ⚠️ Needs post-migration implementation (not blocking testing)

GDPR Requirement #4: Right to Object & Data Portability (Articles 20-21) ​

What's Required ​

GDPR Compliance Checklist (lines 79-90):

  • Marketing opt-out systems
  • JSON/CSV export functionality
  • Identity verification for business data exports
  • Immediate opt-out processing

What's in Migration Plans ​

User consents table (wedissimo-user-migration-revised.md lines 529-550):

php
- consent_type: 'marketing', 'terms', 'privacy', 'cookies'
- granted: boolean
- granted_at / revoked_at timestamps
- consent_method tracking

Marketing consent migration (lines 558-589):

php
- 429 marketing consents from ActiveCampaign
- Creates UserConsent records
- Tracks granted_at timestamps

✅ Data Structure Supports Portability ​

All user and vendor data stored in structured format ready for export:

  • Users table with all profile data
  • Relationships to orders, reviews, favourites
  • Vendors table with business data
  • JSON fields for complex data (package_inclusions, service_attributes)

What's Missing (Post-Migration Implementation) ​

⚠️ Marketing Unsubscribe UI - Not yet implemented

  • Required: One-click unsubscribe links in emails
  • Required: Preference center for granular consent management

⚠️ Data Export Format - Not yet implemented

  • Required: JSON/CSV export endpoints (see Requirement #1)

Status: ⚠️ Needs post-migration implementation (not blocking testing)

GDPR Requirement #5: Consent Management (Article 7) ​

What's Required ​

GDPR Compliance Checklist (lines 92-124):

Couples Consents:

  • Cookie consent banner
  • Marketing email opt-in
  • WhatsApp notifications
  • Vendor contact sharing
  • Review/rating public display

Vendors Consents:

  • Cookie consent banner
  • Business marketing opt-in
  • WhatsApp business notifications
  • Customer contact processing
  • Financial data processing
  • Business profile public display
  • Analytics tracking

What's in Migration Plans ​

User Consents Table (wedissimo-user-migration-revised.md lines 529-550):

php
Schema::create('user_consents', function (Blueprint $table) {
    $table->uuid('id')->primary();
    $table->foreignUuid('user_id')->constrained()->onDelete('cascade');

    // Consent details
    $table->string('consent_type'); // 'terms', 'privacy', 'marketing', 'cookies'
    $table->string('version'); // e.g., '1.0', '2023-08-15'
    $table->boolean('granted')->default(false);
    $table->timestamp('granted_at')->nullable();
    $table->timestamp('revoked_at')->nullable();

    // Audit trail
    $table->string('ip_address')->nullable();
    $table->text('user_agent')->nullable();
    $table->string('consent_method'); // 'registration', 'profile_update', 'cookie_banner', 'email'
    $table->text('notes')->nullable();

    $table->timestamps();
});

Migration of Existing Consents (lines 558-611):

php
// Migrates 429 marketing consents from ActiveCampaign
// Creates baseline consent records for terms and privacy
// Tracks consent_method as 'registration'
// Uses WordPress user_registered as granted_at timestamp

Granular Consent Types Supported:

  • ✅ Marketing consent (migrated from WordPress)
  • ✅ Terms acceptance (assumed at registration)
  • ✅ Privacy policy acceptance (assumed at registration)
  • ✅ Extensible for cookies, WhatsApp, vendor contact sharing, etc.

Audit Trail Complete:

  • ✅ IP address tracking
  • ✅ User agent tracking
  • ✅ Consent method tracking
  • ✅ Version tracking
  • ✅ Granted and revoked timestamps

Status: ✅ FULLY COMPLIANT - Consent management system ready for migration

GDPR Requirement #6: Security Measures (Article 32) ​

What's Required ​

GDPR Master Strategy (lines 169-187):

Minimum Required:

  • HTTPS for all data transmission
  • Role-based access controls
  • Regular security updates
  • Strong password requirements
  • Audit logging

Smart Encryption Strategy:

  • Encrypt: Sensitive contact details, financial info, private communications
  • Keep Unencrypted: Business names, service categories, pricing, descriptions
  • Justification: Searchable marketplace data can remain unencrypted with proper access controls

What's in Migration Plans ​

✅ Access Controls Ready ​

Spatie Permission Integration (wedissimo-user-migration-revised.md lines 197-228):

php
Role::create(['name' => 'wedissimo_admin']);
Role::create(['name' => 'wedissimo_user']);
Role::create(['name' => 'vendor']);
Role::create(['name' => 'customer']);

Role Assignment Logic (lines 321-332):

  • Automated role assignment during migration
  • User types: admin, vendor, customer

✅ Soft Deletes for Data Protection ​

  • Users: line 159
  • Vendors: line 663
  • Listings: line 772

What's Missing (Post-Migration Implementation) ​

⚠️ Selective Encryption - Not yet implemented

  • Required: Encrypt sensitive fields (phone, vat_number, stripe_account_id)
  • Keep unencrypted: names, business_name, location, description
  • Framework: Laravel encryption methods available

⚠️ Audit Logging - Not yet implemented

  • Required: Log all personal data access
  • Required: Track admin actions on user/vendor records
  • Framework: Spatie Laravel Activitylog or similar

Recommendation: Implement in Phase 2 post-migration. Not blocking for initial testing.

Status: ⚠️ Foundation ready, implementation needed post-migration

GDPR Requirement #7: Cross-User Dependencies ​

What's Required ​

GDPR Compliance Checklist (lines 53-78):

Key Challenge:

  • Couples and vendors have interconnected data through bookings
  • Cannot delete couple if vendor needs booking records for tax compliance
  • Cannot delete vendor if couples have active bookings
  • Reviews create cross-user dependencies

What's in Migration Plans ​

✅ Relationship Structure Documented ​

User → Vendor Relationships (wedissimo-user-migration-revised.md lines 1018-1066):

php
public function vendor() // User has one vendor profile
public function listings() // User's listings through vendor
public function orders() // User's bookings/purchases

Vendor → Listing → Bookings (wedissimo-vendors-listings-migration-revised.md):

  • Vendor has many listings
  • Listings have bookings (orders)
  • Creates cross-user dependencies

✅ Approval History Audit Trail ​

Vendor Approval History Table (lines 676-694):

php
Schema::create('vendor_approval_history', function (Blueprint $table) {
    $table->foreignUuid('vendor_id')->constrained()->onDelete('cascade');
    $table->enum('status', ['pending', 'approved', 'rejected']);
    $table->foreignUuid('reviewed_by_user_id')->nullable()->constrained('users');
    $table->timestamp('reviewed_at')->nullable();
    $table->text('notes')->nullable();
    $table->json('onboarding_steps_completed')->nullable();
    $table->json('application_data')->nullable();
});

Purpose: Maintains audit trail for vendor approval/rejection decisions

What's Missing (Post-Migration Implementation) ​

⚠️ Booking Relationship Checks - Domain 3 (Bookings) not yet documented

  • Required: Check active bookings before user/vendor deletion
  • Required: Anonymize data instead of delete when dependencies exist
  • Priority: MEDIUM (Domain 3 will address this)

Recommendation: Implement when Domain 3 (Bookings & Payments) is migrated. Document booking table relationships with users and vendors.

Status: ⚠️ Needs Domain 3 implementation (not blocking Domain 1 & 2 testing)

GDPR Requirement #8: Data Retention ​

What's Required ​

GDPR Master Strategy (lines 366-377):

Data CategoryRetention PeriodProcess
User ProfilesAccount lifetime + 30 daysAutomated
Booking Records7 yearsManual review
Payment Data7 yearsAutomated
Messages1 year post-weddingAutomated
Marketing DataUntil consent withdrawnImmediate
Analytics2 years (anonymized)Automated
Audit Logs6 yearsAutomated
Reviews (anonymized)IndefiniteN/A

What's in Migration Plans ​

✅ Soft Deletes Support Retention ​

Users, Vendors, Listings all have soft deletes:

  • Allows 30-day grace period before permanent deletion
  • Preserves relationships during retention period

User Consents Table has revoked_at field:

  • Tracks when marketing consent withdrawn
  • Can trigger automated data cleanup

What's Missing (Post-Migration Implementation) ​

⚠️ Automated Retention Policy Enforcement - Not yet implemented

  • Required: Scheduled jobs to delete old data based on retention schedules
  • Required: Anonymization of reviews after user deletion
  • Required: 7-year retention for booking/payment records

Recommendation: Implement scheduled tasks in Phase 2:

php
// app/Console/Commands/EnforceDataRetention.php
class EnforceDataRetention extends Command
{
    public function handle()
    {
        // Delete soft-deleted users after 30 days
        User::onlyTrashed()
            ->where('deleted_at', '<', now()->subDays(30))
            ->forceDelete();

        // Anonymize old messages (1 year post-wedding)
        // Delete old analytics (2 years)
        // etc.
    }
}

Status: ⚠️ Needs post-migration implementation (not blocking testing)

What's Required ​

GDPR Compliance Checklist (lines 125-163):

  1. Privacy Policy - Covering both user types with legal basis
  2. Data Processing Agreements (DPAs) - With all third-party processors
  3. Cookie Policy - List all cookies and purposes
  4. Data Breach Response Plan - 72-hour notification process

What's in Migration Plans ​

User Migration Doc (lines 482-490):

- Terms of Use: Page ID 494
- Privacy Policy: Page ID 3
- Last Modified: 2025-08-15

Note: WordPress pages exist but need review/update for GDPR compliance

What's Missing (Manual Process Required) ​

⚠️ Updated Privacy Policy - Current policy needs GDPR compliance review

  • Required: Separate sections for couples vs vendors
  • Required: Article 6 legal basis for each processing activity
  • Required: Data retention schedules
  • Required: User rights procedures
  • Priority: HIGH - Required before go-live

⚠️ DPAs with Third-Party Processors - Not yet in place

  • Required with: Stripe, Google Cloud, Twilio, SendGrid, Fireflies.ai, Google Meet
  • Priority: HIGH - Cannot use processors without DPAs

⚠️ Cookie Policy - Not yet created

  • Required: List all cookies and purposes
  • Priority: MEDIUM - Required for cookie banner

⚠️ Data Breach Response Plan - Not yet documented

  • Required: 72-hour notification process
  • Required: Incident response team assignments
  • Priority: HIGH - Required before go-live

Status: ⚠️ MANUAL PROCESSES REQUIRED (not blocking migration testing, blocks go-live)

Summary: Ready for Testing? ​

✅ YES - Migration Plans Are Ready for Testing ​

Critical GDPR Foundation Complete:

  1. ✅ Soft deletes implemented on all user/vendor/listing tables
  2. ✅ Comprehensive consent management system with full audit trail
  3. ✅ 429 marketing consents migrating from WordPress
  4. ✅ User favourites/wishlists migration (672 records)
  5. ✅ Vendor approval history audit trail
  6. ✅ Role-based access control framework (Spatie Permission)
  7. ✅ All required data fields documented and mapped
  8. ✅ Relationship structures support GDPR rights

What Can Be Tested Immediately:

  • User migration with consent records
  • Vendor migration with approval history
  • Listing migration with package inclusions
  • Role assignments and access controls
  • Soft delete functionality
  • Consent tracking and audit trail

What Needs Post-Migration Implementation (Not Blocking Testing):

  • Data export APIs (can handle manually within 30-day SLA)
  • Cross-user dependency deletion checks (requires Domain 3 bookings)
  • Automated data retention enforcement
  • Selective encryption of sensitive fields
  • Comprehensive audit logging
  • Marketing unsubscribe UI

What Blocks Go-Live (Manual Processes):

  • Updated GDPR-compliant privacy policy
  • DPAs signed with all third-party processors
  • Cookie policy created
  • Data breach response plan documented
  • Staff training on GDPR request handling

Post-Testing Implementation Roadmap ​

Phase 2A: Essential GDPR APIs (Before Go-Live) ​

Week 1-2:

  • [ ] User data export API endpoint
  • [ ] Vendor data export API endpoint
  • [ ] Marketing unsubscribe functionality
  • [ ] Consent preference center UI

Week 3:

  • [ ] Cross-user dependency checks for deletion
  • [ ] Anonymization logic for reviews
  • [ ] Automated data retention jobs

Phase 2B: Enhanced Security (Before Go-Live) ​

Week 4:

  • [ ] Selective encryption implementation
  • [ ] Audit logging system (Spatie Activitylog)
  • [ ] Security access controls audit

Week 5-6 (Manual Processes):

  • [ ] Privacy policy professional rewrite
  • [ ] DPA collection from all processors
  • [ ] Cookie policy creation
  • [ ] Data breach response plan documentation
  • [ ] Staff training on GDPR procedures

Risk Assessment ​

LOW RISK - Migration Testing ​

Why Safe:

  • Core data structures include all GDPR-required fields
  • Soft deletes prevent accidental data loss
  • Consent system preserves audit trail
  • No legal compliance risk during testing phase

MEDIUM RISK - Pre-Go-Live ​

Risks:

  • Manual data export processes may not meet 30-day SLA if volume high
  • No automated cross-user dependency checks could lead to data inconsistencies
  • Missing DPAs mean cannot legally use third-party processors

Mitigation:

  • Implement Phase 2A APIs before public launch
  • Complete Phase 2C manual processes before processing real customer data
  • Use staging environment with anonymized data for testing

HIGH RISK - Go-Live Without Phase 2 Complete ​

Risks:

  • GDPR violations if unable to fulfill data subject requests
  • Fines up to €20M or 4% of global turnover
  • Reputational damage from data handling issues

Mitigation:

  • Do NOT go live without Phase 2A and 2C complete
  • Phase 2B can follow shortly after launch if needed

Final Recommendation ​

✅ APPROVED FOR TESTING ​

Domain 1 (Users) and Domain 2 (Vendors & Listings) migration plans provide a strong GDPR foundation and are ready for migration testing.

Key Strengths:

  1. Comprehensive consent management with full audit trail
  2. Soft deletes on all personal data tables
  3. Vendor approval history for business compliance
  4. Role-based access control framework
  5. All required data fields mapped and validated

Required Before Go-Live:

  1. Implement Phase 2A GDPR APIs (user/vendor data export, deletion checks)
  2. Complete Phase 2C manual processes (privacy policy, DPAs, breach plan)
  3. Consider Phase 2B security enhancements (encryption, audit logs)

Testing Focus:

  • Verify all migration code executes successfully
  • Validate consent records migrate correctly
  • Test soft delete functionality
  • Confirm role assignments work
  • Check WordPress reference tracking (wp_id)

Proceed with confidence knowing the GDPR foundation is solid.

Document Status: Complete Approval: Ready for Domain 1 & 2 Testing Next Review: After migration testing, before Phase 2 implementation

Wedissimo API Documentation

Copyright © 2025 Wedissimo