# 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.
