feat: flatten routes and merge marketing and onboarding directories
This commit is contained in:
372
prd-template/campreg-compliance-security.md
Normal file
372
prd-template/campreg-compliance-security.md
Normal file
@@ -0,0 +1,372 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user