373 lines
9.1 KiB
Markdown
373 lines
9.1 KiB
Markdown
# 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.
|