# CampReg Compliance and Security Specification **Version:** 0.1 **Date:** 2026-06-01 --- ## 1. Compliance Philosophy CampReg will handle parent data, child data, payment-related data, attendance records, communications, and potentially health/medication information. Compliance must be designed into the product from the start. The product should not over-claim legal compliance without review. Instead, it should implement strong controls that support customer compliance obligations and reduce risk. Core principle: > Parent consent, child data minimization, provider-scoped access, auditability, and payment tokenization are foundational requirements. --- ## 2. Data Roles CampReg likely plays different roles depending on data type and contract structure. ### 2.1 Platform Operator CampMatch/CampReg operates the marketplace, parent accounts, provider onboarding, and platform analytics. ### 2.2 Processor / Service Provider For provider-owned registration and operational data, CampReg will often act as a processor/service provider on behalf of the camp/provider. ### 2.3 Controller / Business for Marketplace Data For marketplace search, listing views, saved camps, parent accounts, and marketplace analytics, CampMatch may act as controller/business depending on jurisdiction. This must be clarified in legal terms and privacy policy. --- ## 3. Canada Compliance Areas ## 3.1 PIPEDA CampReg must account for Canadian private-sector privacy requirements, including: - Meaningful consent - Limited collection - Limited use and disclosure - Safeguards appropriate to sensitivity - Accuracy - Access requests - Correction requests - Retention limits - Breach reporting where required Product requirements: - Consent capture during account creation and registration - Privacy policy acceptance log - Marketing consent separated from operational consent - Data export request workflow - Data deletion request workflow - Data retention settings - Breach incident workflow ## 3.2 Provincial Considerations Some provinces have their own privacy frameworks or additional requirements. The product should be designed to handle province-specific notices, retention policies, and consent language. ## 3.3 Quebec Law 25 Considerations If operating in Quebec or serving Quebec providers/families, design for stricter privacy expectations: - Clear privacy officer/contact - Privacy impact assessment support - Consent tracking - Data governance - Breach/incident recordkeeping - Individual rights handling - Transparency around automated decision-making if AI recommendations materially affect users Product requirements: - Consent versioning - Privacy request workflow - Data inventory - Configurable retention - AI explanation for recommendations - Human review for provider-impacting automation --- ## 4. United States Compliance Areas ## 4.1 COPPA Because the product handles information about children under 13, COPPA considerations matter even if parents are the primary users. Design requirements: - Parent/guardian account controls child profiles - Parent provides consent for collection/use of child data - No independent child accounts by default - No child-directed social features in V1 - Parent access to child information - Parent deletion/correction process - Limited collection and use of child data - No behavioral advertising based on sensitive child data ## 4.2 State Privacy Laws The product should support rights workflows that may be needed under state privacy laws: - Access - Deletion - Correction - Portability/export - Opt-out of certain marketing/data use - Notice of data use ## 4.3 HIPAA-Adjacent Health Data Many camps are not HIPAA-covered entities, but health and medication records are highly sensitive. CampReg should avoid unsupported claims like “HIPAA compliant” unless legal and technical validation is completed. Safer positioning: > Built with HIPAA-aligned health data controls. Required controls: - Health module visible only to authorized roles - Medication records separated from general camper profile - Medication dispense audit trail - Timestamp and staff attribution - Access logs - Exportable records - Health data retention rules --- ## 5. Payments and PCI CampReg should reduce PCI scope by using a third-party payment processor such as Stripe. Requirements: - Do not store raw card numbers - Do not store CVV - Use hosted checkout or secure processor components where possible - Store processor customer IDs and payment IDs only - Store last 4, brand, and expiration summary if needed - Use webhooks from processor for payment status - Support refunds through processor APIs - Maintain payment audit trail --- ## 6. Consent Model Consent must be specific, versioned, and auditable. Consent categories: - Platform terms acceptance - Privacy policy acceptance - Registration consent - Waiver/agreement signatures - Payment authorization - Operational email consent - Operational SMS consent - Marketing email consent - Marketing SMS consent - Data sharing with provider - Optional AI personalization/data use consent Required fields: - user_id - family_id nullable - consent_type - consent_version - consent_status - granted_at - revoked_at - ip_address - user_agent --- ## 7. Role-Based Access Control Required roles: - Platform Admin - Provider Owner - Camp Director - Registrar/Admin - Finance Staff - Medical Staff - Counselor - Marketing Staff - Parent/Guardian Sensitive permissions: - View medical records - Edit medical records - Dispense medication - View incident reports - View financial records - Issue refunds - Send mass messages - Export data - Manage staff roles - Manage API keys --- ## 8. Audit Logging Audit logs are required for safety, compliance, support, and trust. Audit events: - Login - Password/auth changes - Role changes - Child profile edits - Emergency contact edits - Pickup authorization edits - Registration changes - Form submissions - Waiver signatures - Payment events - Refunds - Attendance check-in/out - Health data access - Medication dispense - Incident creation/update - Mass messages - API key creation/revocation - Webhook changes --- ## 9. Data Minimization Data should only be collected when needed for discovery, registration, safety, operations, payments, or growth automation. Examples: - CampMatch matching does not need full medical history. - Marketing does not need medication details. - Counselors may need allergy flags but not full medical records. - Providers should not see unrelated family activity with other providers. --- ## 10. AI and VibnAI Safety VibnAI must not use sensitive child data in marketing copy or unsafe targeting. Required AI controls: - Human approval for outbound campaigns - No public exposure of individual child data - No targeting based on sensitive health information - Explain why recommendations are made - Keep audit trail of generated, edited, approved, and published content - Allow provider brand rules - Allow prohibited claims list --- ## 11. Mobile Security Mobile risks include lost devices, shared devices, staff turnover, and field use. Requirements: - Session expiration - MFA option - Role-based mobile views - Minimal sensitive offline cache - Encrypted offline cache if used - Remote logout/session revocation - Staff access removal workflow - Audit logs for sensitive views/actions --- ## 12. Security Architecture Requirements Required: - HTTPS everywhere - Encryption at rest - Strong password/auth provider controls - MFA support - Secure file storage - Malware scanning for uploads where possible - Signed URLs for documents - Environment secret management - Least-privilege service accounts - Database backups - Disaster recovery plan - Monitoring and alerting - Rate limiting - WAF/CDN where appropriate - Vulnerability scanning - Dependency scanning --- ## 13. Data Export and Deletion Parents should be able to request: - Copy of family data - Copy of child data - Correction - Deletion where legally permitted Providers should be able to export: - Registration records - Rosters - Attendance records - Payment reports - Form submissions - Communication history Deletion must account for: - Legal retention - Payment/tax records - Safety records - Provider contractual obligations - Backup retention windows --- ## 14. Breach and Incident Response Required internal workflow: 1. Detect incident 2. Contain incident 3. Assess data affected 4. Identify affected users/providers 5. Determine notification obligations 6. Notify where required 7. Remediate 8. Record incident 9. Update controls --- ## 15. Cloud Platform Considerations The product can be built securely on either Google Cloud or AWS. Given existing ecosystem direction, GCP is a strong fit if CampReg uses: - Cloud Run for services - Cloud SQL PostgreSQL for operational database - Firebase Auth / Identity Platform for authentication - Cloud Storage for documents - BigQuery for analytics - Vertex AI for AI workflows - Secret Manager for secrets - Cloud Logging/Monitoring for observability Key requirement is not simply choosing the cloud provider. It is implementing proper security architecture, tenancy, access control, audit logging, and compliance workflows.