# Security Practices **GuardianOx — guardianox.com** **Last Updated:** March 17, 2026 --- ## 1. Overview GuardianOx is committed to protecting the data entrusted to us by home care agencies. This document describes the security practices we implement to safeguard scheduling data, communication records, and any information that may constitute Protected Health Information (PHI) under HIPAA. Our security approach is built on four principles: encryption, access control, audit logging, and data minimization. --- ## 2. Encryption ### 2.1 Data in Transit All data transmitted to and from GuardianOx is encrypted using HTTPS with TLS 1.2 or higher. This applies to: - Web browser connections to guardianox.com - All API requests and responses - Webhook deliveries - Internal service-to-service communication We enforce HTTPS on all endpoints. Unencrypted HTTP connections are automatically redirected to HTTPS. ### 2.2 Data at Rest Data stored in our systems is encrypted at rest: - **Redis data store:** Encrypted using the encryption-at-rest capabilities provided by our managed Redis provider - **Backups:** All backup copies are encrypted using AES-256 encryption - **Log files:** Stored in encrypted storage volumes ### 2.3 SMS Communication SMS messages are transmitted via Twilio's infrastructure, which encrypts messages in transit. Note that SMS is inherently less secure than encrypted messaging protocols once messages arrive on recipient devices. We inform agencies of this limitation so they can make appropriate decisions about what information is communicated via SMS. --- ## 3. Access Controls ### 3.1 API Authentication All API access requires authentication via API keys. Each agency receives unique API keys that: - Are generated using cryptographically secure random number generation - Must be included in all API requests - Can be rotated by the agency at any time - Are stored in hashed form in our systems ### 3.2 Role-Based Access (Planned) We are implementing role-based access control (RBAC) to provide granular permission management within agency accounts. This will include: - Administrator: Full access to all features and settings - Scheduler: Access to scheduling and communication features - Read-only: View-only access to schedules and reports Until RBAC is fully deployed, all authenticated users within an agency have equivalent access. ### 3.3 Internal Access Access to GuardianOx production systems is restricted to: - Essential engineering personnel only - Requires multi-factor authentication - All access is logged and auditable - Access is reviewed regularly and revoked when no longer needed ### 3.4 Third-Party Access No third-party service has standing access to client data. Third-party services (Twilio, Groq) receive only the minimum data necessary to perform their function: - **Twilio:** Receives phone numbers and message content for SMS delivery - **Groq:** Receives scheduling context for AI processing. No PHI is included in prompts sent to Groq --- ## 4. Audit Logging ### 4.1 What We Log All API calls to the GuardianOx platform are logged with the following information: - **Timestamp:** When the action occurred (UTC) - **Actor:** Which API key or user initiated the action - **Action:** What operation was performed (e.g., create shift, send SMS, generate report) - **Resource:** Which data was affected - **Result:** Whether the action succeeded or failed - **Source IP:** The IP address of the request ### 4.2 Log Retention Audit logs are retained for a minimum of 12 months. Logs are stored in encrypted storage and are not modifiable after creation. ### 4.3 Log Access Audit logs are accessible to: - Agency administrators (their own agency's logs) via the platform dashboard - GuardianOx security personnel for incident investigation - As required by law or legal process ### 4.4 Monitoring We monitor audit logs for anomalous activity, including: - Unusual API call volumes - Access from unexpected IP addresses - Repeated authentication failures - Bulk data access patterns --- ## 5. Data Minimization ### 5.1 Principle GuardianOx collects and stores only the minimum data necessary to provide scheduling and communication services. We do not collect or store clinical records, medical diagnoses, treatment plans, medications, or other health-related information beyond what is needed for scheduling. ### 5.2 What We Store | Data Type | Purpose | Stored | |-----------|---------|--------| | Caregiver names | Shift assignment | Yes | | Caregiver phone numbers | SMS notifications | Yes | | Client (patient) names | Scheduling reference | Yes | | Shift times and assignments | Core scheduling | Yes | | SMS message content | Communication records | Yes | | Family member phone numbers | Family updates | Yes | | Medical diagnoses | Not applicable | No | | Treatment plans | Not applicable | No | | Medication lists | Not applicable | No | | Insurance information | Not applicable | No | | Social Security numbers | Not applicable | No | ### 5.3 AI Data Handling When using AI features (powered by Groq), we construct prompts that include only scheduling context (shift times, caregiver availability, assignment constraints). Patient identifiers and any PHI are excluded from AI processing prompts. --- ## 6. Incident Response Procedure ### 6.1 Detection Security incidents may be detected through: - Automated monitoring and alerting systems - Audit log analysis - Reports from clients or employees - Reports from third-party security researchers ### 6.2 Classification Incidents are classified by severity: - **Critical:** Confirmed breach of PHI or client data; active unauthorized access to production systems - **High:** Suspected breach; vulnerability with potential for data exposure - **Medium:** Security misconfiguration; unsuccessful attack attempt - **Low:** Minor policy violation; informational security event ### 6.3 Response Upon detection of a security incident: 1. **Containment (Immediate):** Isolate affected systems, revoke compromised credentials, block malicious access 2. **Assessment (Within 24 hours):** Determine scope, identify affected data and clients, classify severity 3. **Notification (Within 72 hours):** Notify affected agencies and individuals as required (see Breach Notification below) 4. **Remediation:** Fix the root cause, restore affected systems, strengthen controls 5. **Post-Incident Review:** Document findings, update procedures, implement preventive measures --- ## 7. Breach Notification ### 7.1 Timeline In the event of a confirmed breach of unsecured PHI, GuardianOx will: - Notify affected agencies within **72 hours** of discovery - Cooperate with agencies in their notification obligations to affected individuals and HHS - Provide a written incident report within 30 days ### 7.2 Notification Content Breach notifications will include: - Description of the incident - Types of data involved - Individuals potentially affected - Steps taken to contain and remediate the breach - Recommendations for affected individuals - Contact information for further inquiries ### 7.3 Regulatory Reporting GuardianOx will cooperate with agencies in fulfilling their breach notification obligations under HIPAA, including notifications to the Department of Health and Human Services (HHS) and, where applicable, media notification. See our detailed [Breach Notification Procedure](./breach-notification-procedure.md) for the full step-by-step process. --- ## 8. Vulnerability Management ### 8.1 Dependency Updates Software dependencies are reviewed and updated regularly to address known security vulnerabilities. Critical security patches are applied within 72 hours of release. ### 8.2 Security Testing We conduct periodic security reviews of our codebase and infrastructure. This includes: - Code review for security issues during development - Dependency vulnerability scanning - Infrastructure configuration review ### 8.3 Responsible Disclosure Security researchers who discover vulnerabilities in GuardianOx systems are encouraged to report them to hello@guardianox.com. We commit to acknowledging reports within 48 hours and providing regular updates on remediation progress. --- ## 9. Physical Security GuardianOx operates as a cloud-based service. Physical security is provided by our cloud infrastructure provider, which maintains: - Data center physical access controls - Environmental controls (fire suppression, climate control, power redundancy) - SOC 2 compliance --- ## 10. Employee Security ### 10.1 Access Provisioning Employee access to systems is granted on a need-to-know basis and reviewed regularly. ### 10.2 Security Awareness All personnel with access to production systems receive training on data handling, HIPAA requirements, and security best practices. ### 10.3 Offboarding When an employee leaves or changes roles, access to production systems is revoked within 24 hours. --- ## 11. Regular Review Schedule | Activity | Frequency | |----------|-----------| | Access control review | Quarterly | | Audit log review | Monthly | | Dependency vulnerability scan | Weekly (automated) | | Security practices review | Semi-annually | | Incident response plan review | Annually | | BAA compliance review | Annually | | Full security assessment | Annually | --- ## 12. Contact For security questions, vulnerability reports, or incident reports: **GuardianOx** Email: hello@guardianox.com Website: guardianox.com For urgent security matters, include "URGENT: Security" in the subject line.