1. Overview
This Security Addendum ("Addendum") describes the security measures, certifications, and practices that Glass Box Solutions, Inc. ("Provider") implements to protect Customer data within the Adjudica.AI platform (the "Service"). This Addendum is incorporated into the Master Subscription Agreement or Terms of Service.
2. Security Certifications and Compliance
2.1 Current Certifications
| Certification | Status | Scope |
|---|
| SOC 2 Type II | [In Progress / Achieved] | Security, Availability, Confidentiality |
| HIPAA | Compliant | PHI handling and safeguards |
2.2 Compliance Frameworks
Provider maintains compliance with:
- HIPAA Security Rule (45 CFR Part 164, Subpart C)
- HIPAA Privacy Rule (45 CFR Part 164, Subpart E)
- CCPA/CPRA (California Consumer Privacy Act / California Privacy Rights Act)
- CalOPPA (California Online Privacy Protection Act)
- CMIA (California Confidentiality of Medical Information Act)
- SOC 2 Trust Service Criteria (Security, Availability, Confidentiality)
2.3 Third-Party Audits
- Penetration Testing: Conducted annually by independent security firm
- Vulnerability Assessments: Conducted quarterly
- SOC 2 Audit: Conducted annually by licensed CPA firm
- HIPAA Risk Assessment: Conducted annually
3. Infrastructure Security
3.1 Cloud Infrastructure
The Service is hosted on Google Cloud Platform (GCP), which maintains:
- SOC 1/2/3 certification
- ISO 27001, 27017, 27018 certification
- FedRAMP Authorization
- HIPAA BAA execution
- PCI DSS compliance
3.2 Network Security
| Control | Implementation |
|---|
| Firewall | Cloud-native firewall with default-deny policies |
| DDoS Protection | Cloud Armor DDoS mitigation |
| Network Segmentation | VPC isolation between environments |
| Intrusion Detection | Cloud-native IDS/IPS monitoring |
| WAF | Web Application Firewall for application layer protection |
3.3 Physical Security
Google Cloud data centers provide:
- 24/7 security personnel
- Biometric access controls
- Video surveillance
- Environmental controls (fire suppression, climate control)
- Redundant power systems
4. Data Security
4.1 Encryption
| Data State | Encryption Standard |
|---|
| Data at Rest | AES-256 |
| Data in Transit | TLS 1.3 (minimum TLS 1.2) |
| Database Encryption | AES-256 with Google-managed keys |
| Backup Encryption | AES-256 |
| API Communications | TLS 1.3 with certificate pinning |
4.2 Key Management
- Encryption keys managed via Google Cloud KMS
- Automatic key rotation (annual minimum)
- Separation of key management from data access
- Hardware Security Module (HSM) backing for sensitive keys
4.3 Data Isolation
| Isolation Type | Implementation |
|---|
| Tenant Isolation | Logical separation with unique tenant identifiers |
| Database Isolation | Row-level security policies |
| Storage Isolation | Separate storage containers per tenant |
| Processing Isolation | Containerized workloads |
4.4 Data Classification
| Classification | Examples | Handling |
|---|
| PHI | Medical records, patient identifiers | Encrypted, access-logged, minimum necessary |
| Confidential | Attorney work product, case strategies | Encrypted, access-controlled |
| Internal | System logs, analytics | Encrypted at rest |
| Public | Marketing materials | Standard protection |
5. Access Control
5.1 Authentication
| Control | Implementation |
|---|
| Password Requirements | Minimum 12 characters, complexity requirements |
| Multi-Factor Authentication | TOTP, SMS, or hardware key (required for admin) |
| Single Sign-On | SAML 2.0, OAuth 2.0 (Enterprise) |
| Session Management | Automatic timeout, secure session tokens |
| Account Lockout | 5 failed attempts triggers temporary lockout |
5.2 Authorization
- Role-Based Access Control (RBAC): Permissions assigned by role
- Principle of Least Privilege: Minimum necessary access
- Segregation of Duties: Critical functions require multiple approvals
- Regular Access Reviews: Quarterly review of user permissions
5.3 Administrative Access
| Control | Implementation |
|---|
| Admin MFA | Required for all administrative access |
| Privileged Access Management | Just-in-time access, approval workflows |
| Admin Activity Logging | All administrative actions logged and monitored |
| Background Checks | Required for employees with data access |
6. Application Security
6.1 Secure Development Lifecycle (SDLC)
| Phase | Security Activities |
|---|
| Design | Threat modeling, security requirements |
| Development | Secure coding standards, peer review |
| Testing | SAST, DAST, dependency scanning |
| Deployment | Infrastructure as code, immutable deployments |
| Operations | Runtime protection, monitoring |
6.2 Vulnerability Management
| Activity | Frequency |
|---|
| Automated Vulnerability Scanning | Continuous |
| Dependency Scanning | Every build |
| Penetration Testing | Annual (third-party) |
| Bug Bounty Program | [Planned/Active] |
6.3 Patch Management
| Severity | Patch Timeline |
|---|
| Critical (CVSS 9.0+) | 24 hours |
| High (CVSS 7.0-8.9) | 7 days |
| Medium (CVSS 4.0-6.9) | 30 days |
| Low (CVSS 0.1-3.9) | 90 days |
7. AI Security
7.1 AI Provider Security
Our AI provider (Google) is:
- Bound by a Business Associate Agreement
- Contractually prohibited from using customer data for model training
- Required to delete data after processing
- Subject to security assessment
7.2 AI-Specific Controls
| Control | Implementation |
|---|
| Prompt Injection Prevention | Input validation, output filtering |
| Data Leakage Prevention | No PHI or case content in model training |
| Output Validation | Automated review of AI outputs |
| Audit Logging | All AI interactions logged |
7.3 Model Training Prohibition
PHI, document content, and confidential legal information are NEVER used for AI model training. This is enforced through:
- Contractual prohibitions with AI providers
- API configurations that disable training
- Technical controls preventing data retention
Note: De-identified behavioral signals (classification corrections, quality feedback, usage patterns) may be used for platform improvement. These signals contain no PHI or case content. See Platform Improvement Data Policy for details.
8. Monitoring and Logging
8.1 Security Monitoring
| Monitoring Type | Coverage |
|---|
| SIEM | Centralized log analysis and alerting |
| Intrusion Detection | Network and host-based IDS |
| Anomaly Detection | Behavioral analysis for unusual activity |
| Real-time Alerting | 24/7 security event notification |
8.2 Audit Logging
| Log Type | Retention | Content |
|---|
| Authentication Logs | 6 years | Login attempts, MFA events, session activity |
| Access Logs | 6 years | Data access, document views, exports |
| Administrative Logs | 6 years | Configuration changes, user management |
| API Logs | 6 years | API calls, request/response metadata |
| Security Logs | 6 years | Security events, alerts, incidents |
8.3 Log Protection
- Logs are encrypted at rest and in transit
- Write-once storage prevents tampering
- Access to logs is restricted and audited
- Logs are backed up to separate storage
9. Incident Response
9.1 Incident Response Program
Provider maintains a documented Incident Response Plan including:
- Incident classification criteria
- Response team roles and responsibilities
- Communication procedures
- Forensic investigation procedures
- Post-incident review process
9.2 Incident Classification
| Severity | Definition | Response Time |
|---|
| Critical | Confirmed breach of PHI or confidential data | Immediate |
| High | Potential breach or significant vulnerability | 1 hour |
| Medium | Security event requiring investigation | 4 hours |
| Low | Minor security event | 24 hours |
9.3 Breach Notification
In the event of a security incident involving Customer data:
| Notification | Timeline |
|---|
| Initial Notification | Within 24 hours of confirmed breach |
| Detailed Report | Within 72 hours |
| Final Report | Within 30 days |
| HIPAA Notification | Per BAA requirements (within 10 days) |
10. Business Continuity
10.1 Disaster Recovery
| Metric | Target |
|---|
| Recovery Time Objective (RTO) | 4 hours |
| Recovery Point Objective (RPO) | 1 hour |
| Backup Frequency | Continuous + daily full backup |
| Geographic Redundancy | Multi-region replication |
10.2 Business Continuity Testing
- DR Testing: Conducted annually
- Tabletop Exercises: Conducted semi-annually
- Backup Restoration Testing: Conducted quarterly
11. Personnel Security
11.1 Employee Security
| Control | Requirement |
|---|
| Background Checks | Required for all employees with data access |
| Security Training | Annual security awareness training |
| HIPAA Training | Annual HIPAA-specific training |
| Confidentiality Agreements | Required for all employees and contractors |
| Access Termination | Same-day access revocation upon termination |
11.2 Vendor Security
Third-party vendors with access to customer data must:
- Complete security questionnaire
- Sign confidentiality agreements
- Maintain appropriate certifications
- Undergo periodic security review
12. Customer Security Responsibilities
Customers are responsible for:
| Responsibility | Description |
|---|
| Account Security | Protecting login credentials, enabling MFA |
| User Management | Managing authorized users, prompt deprovisioning |
| Data Classification | Identifying PHI and confidential information |
| Incident Reporting | Promptly reporting suspected security issues |
| Compliance | Ensuring use complies with applicable law |
13. Security Documentation
Upon request, Provider will provide:
| Document | Availability |
|---|
| SOC 2 Type II Report | Under NDA |
| Penetration Test Executive Summary | Under NDA |
| Security Questionnaire Responses | Standard SIG/CAIQ |
| HIPAA Compliance Documentation | Per BAA |
| Certificate of Insurance | Upon request |
14. Security Contact
15. Updates to This Addendum
Provider may update this Security Addendum to reflect improvements to security practices. Material changes will be communicated to Customers with at least 30 days' notice. Updates will not materially reduce security protections during an active subscription term.
This Security Addendum is effective as of [INSERT DATE].
Glass Box Solutions, Inc.