9.1 KiB
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:
- Detect incident
- Contain incident
- Assess data affected
- Identify affected users/providers
- Determine notification obligations
- Notify where required
- Remediate
- Record incident
- 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.