Trust & Compliance
HIPAA-compliant, GDPR-ready, research-backed — built for the trust that personality data demands.
Personality data is sensitive data, and the systems that handle it must earn trust through architecture, not promises. From PHI scrubbing to hash-chain audit trails, every layer of the system is built for the trust that personality data demands.
Personality Data Is Sensitive Data
A personality assessment captures how a person processes emotion, where their attention locks, how they form attachments, and where their system breaks down under stress. This is not the same category of data as a music preference or a shopping history. It is intimate, clinically relevant, and — if mishandled — genuinely harmful.
Icosa treats it accordingly. The compliance infrastructure is not a checkbox exercise bolted on after launch. It is woven into the architecture: 13 HIPAA modules, 20 GDPR modules, PHI scrubbing at every output boundary, audit trails with cryptographic integrity verification, and a data security posture built for clinical use.
HIPAA Compliance
The Health Insurance Portability and Accountability Act sets the standard for protecting health information in the United States. Icosa implements HIPAA through 13 dedicated modules covering the full lifecycle of protected health information.
PHI Identification and Scrubbing
Every piece of data that enters or leaves the system passes through a 9-pattern PHI scrubber. The patterns are specific and deliberately comprehensive:
| Pattern | What It Catches |
|---|---|
| Email addresses in any format | |
| SSN | Social Security Numbers (with and without dashes) |
| Phone | Phone numbers in all common formats |
| Dates | Date patterns that could identify individuals |
| IP | IP addresses (v4 and v6) |
| UUID | Universally unique identifiers |
| MRN | Medical Record Numbers |
| ZIP | ZIP codes (which can be geographically identifying) |
| Signature | Assessment signature strings that encode responses |
The scrubber runs on all narrative output, all exported data, and all data surfaced to any user interface. It is not optional and cannot be disabled.
HIPAA Mode for AI Features
When the system generates AI narratives — the natural-language interpretation of assessment results — the LLM receives clinical data as part of the prompt. In HIPAA mode, the raw LLM response is cleared immediately after extraction. This prevents PHI from persisting in cached responses, log files, or error reports.
This addresses a risk specific to AI-powered clinical tools: the LLM may echo back identifiable information from the prompt. By clearing the raw response and retaining only the structured extraction, the system eliminates this PHI echo vector entirely.
Data Integrity and Audit Trails
Every access to protected health information is logged with timestamp, user, action, and purpose. The audit trail uses a cryptographic hash chain — each entry’s integrity hash includes the previous entry’s hash, creating a tamper-evident sequence. If any entry is modified or deleted after the fact, the chain breaks and the tampering is detectable.
The audit log supports query and verification from the admin dashboard. Integrity verification checks the full hash chain and reports any breaks. This is not just logging — it is forensically sound record-keeping.
Additional HIPAA Modules
| Module | Purpose |
|---|---|
| PHI field tracking | Every database column containing PHI is identified and tagged |
| Encryption at rest | All stored data encrypted with rotatable keys |
| Key rotation | Encryption keys can be rotated without downtime; rotation history maintained |
| Break-glass access | Emergency access procedure with full logging for clinical emergencies |
| 7-year retention | Clinical records retained for the legally required period |
| Minimum necessary | Access controls enforce the principle of minimum necessary access |
| Access controls | Role-based access with 4 tiers (consumer, clinician, admin, super_admin) |
How PHI Protection Works End-to-End
PHI protection in Icosa operates at four layers, each addressing a different attack surface.
Storage layer — All PHI-containing tables are identified in a central registry. Encryption at rest means the data is unreadable without the current encryption key. Key rotation allows the key to be changed without re-encrypting existing data (new writes use the new key; reads decrypt with the appropriate key version).
Processing layer — When data is computed or analyzed, PHI is available only within the secure processing boundary. The 9-pattern scrubber runs on all outputs before they leave the processing boundary. HIPAA mode clears raw LLM responses immediately after structured extraction.
Access layer — Role-based access controls mean a consumer sees only their own data, a clinician sees only their connected clients’ data, and an admin sees aggregate statistics without individual PHI unless break-glass access is invoked. Every access is logged.
Audit layer — The hash chain audit trail provides tamper-evident logging. Integrity verification can be run at any time. Break-glass access creates a high-priority audit entry that is flagged for review.
GDPR Compliance
The General Data Protection Regulation governs data protection and privacy in the European Union. Icosa implements GDPR through 21 dedicated modules covering consent, data subject rights, breach management, and ongoing compliance monitoring.
Data Subject Requests
GDPR grants individuals 8 types of data subject requests. The system supports all of them through a self-service privacy dashboard and an admin approval workflow:
| DSR Type | What It Does |
|---|---|
| Access | Export all personal data as structured JSON |
| Rectification | Correct inaccurate personal data |
| Erasure | Delete all personal data with cascade across all related tables |
| Restriction | Limit processing of personal data while a dispute is resolved |
| Portability | Export data in a machine-readable format for transfer to another service |
| Objection | Object to specific processing activities |
| Consent withdrawal | Withdraw previously granted consent for specific purposes |
| Automated decision objection | Object to decisions made solely by automated processing |
Erasure is the most technically demanding: a single erasure request triggers a cascade deletion across 12 tables, removing assessment data, clinical notes, behavioral signals, cached computations, narrative outputs, sharing links, and all associated metadata. The cascade is atomic — it either completes fully or rolls back entirely.
Consent Management
Consent is purpose-specific and granular. Each processing purpose requires its own consent grant, and each can be withdrawn independently. The system tracks consent status, grant timestamps, and withdrawal timestamps. Processing is blocked for any purpose where active consent does not exist.
Multi-reporter consent adds a layer of complexity: when a third-party reporter (a clinician or partner) assesses someone, the subject must consent to that specific assessment. The consent flow ensures no one is assessed without their knowledge.
Breach Management
GDPR requires notification of data breaches within 72 hours. The system implements a full breach lifecycle:
- Register — Document the breach with initial details
- Assess — Evaluate scope, affected data subjects, and severity
- Contain — Implement containment measures and document them
- Notify authority — Generate and send Data Protection Authority notification
- Notify subjects — Generate and send affected individual notifications
- Resolve — Document root cause, remediation, and lessons learned
A 72-hour countdown timer starts at registration. The admin dashboard tracks the countdown and escalates visibility as the deadline approaches. Root cause tracking ensures that each breach type is analyzed for systemic issues.
All 21 GDPR Modules
| Module | Purpose |
|---|---|
| Consent management | Purpose-specific consent grants and withdrawals |
| 8 DSR types | Full lifecycle for each data subject request type |
| Data export | Complete personal data export as structured JSON |
| Breach registration | Initial breach documentation |
| Breach assessment | Scope and severity evaluation |
| Breach containment | Containment measure documentation |
| Breach notification (authority) | DPA notification generation |
| Breach notification (subjects) | Affected individual notification |
| Breach resolution | Root cause and remediation |
| 72-hour countdown | Automated deadline tracking |
| Processing activity registry | Documentation of all processing activities |
| Sub-processor management | Third-party processor tracking and compliance |
| International transfer documentation | Cross-border data transfer records |
| Data Protection Impact Assessments | DPIAs for high-risk processing |
| Compliance monitoring alerts | Automated compliance status monitoring |
| Cookie and privacy policies | Policy management and versioning |
| Multi-reporter consent | Third-party reporter consent flow |
| Data governance dashboard | Centralized compliance overview |
| Retention policy | Automated purging per retention schedules |
| Data governance configuration | DPO, EU representative, and controller details |
| Profiling disclosure | Article 22 disclosure for automated decision-making |
Data Security Architecture
The technical infrastructure behind the compliance modules is designed for clinical-grade data handling.
Database — Production-grade relational database — not a lightweight embedded database, but a full server-grade system designed for clinical data volumes. Connection pooling manages concurrent access. All queries run through parameterized statements (no raw SQL string interpolation) to prevent injection.
Encryption — Data encrypted at rest with rotatable keys. Encryption key management includes rotation capability and rotation history. Share links use visibility bitmasks and expiration timestamps to limit exposure.
Authentication — Passwordless authentication: you sign in by clicking a secure link sent to your email — no password to remember, leak, or guess. Bearer tokens in Authorization headers. Four-role access control: consumer, clinician, admin, super_admin. Multi-factor authentication support. Role-based access enforced at the API layer.
Session analysis — Therapy transcripts pasted into the session analysis tool are never stored. They are PII-scrubbed, analyzed, and discarded in a single processing cycle. Only the structured analysis results persist. This is a deliberate architectural decision: the most sensitive data (raw therapy sessions) never touches the database.
Secure sharing — Assessment results can be shared via encrypted share links with configurable visibility (which sections are visible) and automatic expiration. Public profile views use signature-based access that reveals the grid state but not the person’s identity.
Assessment Integrity
A personality assessment is only useful if the data is trustworthy. The system includes multiple layers of integrity checking:
Behavioral signal detection captures 23 signals across 5 categories during every assessment. These signals detect rushing, careless responding, monotonic patterns, and gaming attempts — without the person being aware they are being observed. The behavioral layer does not alter scores; it provides metadata that clinicians and the system use to weight confidence.
Tier-based confidence scales with assessment depth: a 10-question Quick assessment (2 minutes) carries 0.30 confidence. A 32-question Standard assessment (5 minutes) carries 0.70. A 91-question Comprehensive assessment (15 minutes) carries 1.00. The system does not pretend a 2-minute assessment is as reliable as a 15-minute one.
Age-adjusted thresholds modify behavioral signal interpretation by age group. Response time expectations for a 10-year-old differ from those for a 45-year-old. The system accounts for this rather than applying a single set of norms across all ages.
Noise robustness has been tested extensively: the classifier maintains 100% accuracy at zero noise and 98.8% at noise level 0.1. The system degrades gracefully rather than catastrophically under measurement noise.
Research Backing
The Icosa model is backed by 78 computational studies spanning grid geometry, coherence analysis, formation theory, dyadic systems, clinical utility, and robustness testing — synthesized into 15 peer-reviewable papers and a comprehensive meta-analysis. The research corpus validates structural independence of the four Capacities, measurement equity across demographics, convergent validity with seven established personality systems, and high accuracy under simulated noise. Every study is available as a downloadable PDF with full methodology and data archives on the research hub.
Why This Matters
Compliance is not a feature. It is a prerequisite. A personality assessment platform that handles sensitive psychological data without clinical-grade security and regulatory compliance is not a product — it is a liability.
Icosa is built for the use case where compliance is non-negotiable: licensed clinicians, therapy practices, clinical research, and individuals who take their psychological data seriously. Every architectural decision — from the choice to never store therapy transcripts, to the hash chain audit trail, to the 12-table cascade deletion — reflects the principle that personality data deserves the same protection as medical records. Because that is what it is.
See this in your own profile
Take the Assessment →