SOC 2 Type II Self-Assessment Report
Organization: inou
Report Period: January 1, 2026 - Ongoing
Assessment Date: January 25, 2026 (Updated February 1, 2026)
Prepared By: Johan Jongsma, Founder & Owner
Report Version: 1.1
Executive Summary
inou is a medical imaging platform with AI-powered health data exploration. This self-assessment evaluates controls against the AICPA Trust Services Criteria for SOC 2 Type II compliance.
| Category |
Status |
Score |
| Security (CC1-CC9) |
Implemented |
95% |
| Availability (A1) |
Implemented |
95% |
| Processing Integrity (PI1) |
Implemented |
95% |
| Confidentiality (C1) |
Implemented |
98% |
| Privacy (P1-P8) |
Implemented |
95% |
Overall: Controls fully implemented. Minor action items identified for continuous improvement.
1. Security (Common Criteria)
CC1: Control Environment
| Control |
Status |
Evidence |
| CC1.1 Integrity and ethical values |
Implemented |
Privacy policy: no data selling, no AI training, no tracking |
| CC1.2 Board oversight |
N/A |
Single-owner operation; owner has direct oversight |
| CC1.3 Structure and reporting |
Implemented |
Security Policy defines roles |
| CC1.4 Commitment to competence |
Implemented |
Owner: 20+ years enterprise backup/recovery, CTO Backup at Kaseya, founder of IASO Backup (acquired by SolarWinds/N-able) |
| CC1.5 Personnel accountability |
Implemented |
Automated enforcement via make check-db; single admin access |
CC2: Communication and Information
| Control |
Status |
Evidence |
| CC2.1 Internal security info |
Implemented |
Security Policy, CLAUDE.md |
| CC2.2 Policy communication |
Implemented |
Policies in docs/ directory |
| CC2.3 External communication |
Implemented |
/privacy-policy, /security, /legal/dpa |
CC3: Risk Assessment
| Control |
Status |
Evidence |
| CC3.1 Risk assessment process |
Implemented |
Risk Assessment |
| CC3.2 Fraud risk consideration |
Implemented |
Covered in risk assessment |
| CC3.3 Change management risk |
Implemented |
make check-db validates changes |
| CC3.4 Third-party risk |
Implemented |
Minimal dependencies; vendor assessment documented |
CC4: Monitoring Activities
| Control |
Status |
Evidence |
| CC4.1 Ongoing monitoring |
Implemented |
HTTP logs, 404 alerts, rate limiting, Uptime Kuma (Zurich), Nuclei scans |
| CC4.2 Remediation |
Implemented |
Incident Response Plan |
External Monitoring (Added February 2026)
| Tool |
Location |
Purpose |
Frequency |
| Uptime Kuma |
zurich.inou.com:3001 |
Availability monitoring |
Continuous (60s) |
| Nuclei |
zurich.inou.com |
Vulnerability scanning |
Weekly + Monthly |
Why Zurich? External monitoring from Switzerland provides geographic independence and simulates external attacker perspective for vulnerability assessment.
CC5: Control Activities
| Control |
Status |
Evidence |
| CC5.1 Control selection |
Implemented |
Defense-in-depth architecture |
| CC5.2 Technology controls |
Implemented |
FIPS 140-3, AES-256-GCM, TLS 1.3 |
| CC5.3 Control deployment |
Implemented |
Data layer enforcement in lib/ |
CC6: Logical and Physical Access
| Control |
Status |
Evidence |
| CC6.1 Logical access |
Implemented |
Token auth, OAuth 2.0 + PKCE, encrypted sessions |
| CC6.2 Authentication |
Implemented |
Passwordless (email codes), 4-hour token expiry |
| CC6.3 Access removal |
Implemented |
Automatic token expiration |
| CC6.4 Authorization |
Implemented |
RBAC with permission inheritance |
| CC6.5 Physical access |
Implemented |
Private secure facility with alarm, FDE; see Physical Security |
| CC6.6 Asset disposal |
Implemented |
Physical destruction of failed storage media |
| CC6.7 Malware protection |
Implemented |
OS hardening, AppArmor, auto-updates; see OS Hardening |
| CC6.8 Infrastructure security |
Implemented |
Isolated VLAN, zone-based firewall, default-deny rules |
CC7: System Operations
| Control |
Status |
Evidence |
| CC7.1 Anomaly detection |
Implemented |
Tarpit, 404 monitoring, rate limiting, Uptime Kuma alerts |
| CC7.2 Incident monitoring |
Implemented |
Access logs, alert notifications, Uptime Kuma webhook → James AI |
| CC7.3 Incident response |
Implemented |
Incident Response Plan |
| CC7.4 Recovery |
Implemented |
Disaster Recovery Plan |
Vulnerability Scanning Program (Added February 2026)
| Schedule |
Scan Type |
Tool |
Targets |
| Monthly (1st) |
Full vulnerability scan |
Nuclei |
inou.com |
| Weekly (Sunday) |
Critical/High/Medium |
Nuclei |
inou.com |
| Ad-hoc |
Pre-release |
Nuclei |
inou.com, dev.inou.com |
Baseline Scan (January 31, 2026):
- 34 findings, all informational
- No critical, high, or medium vulnerabilities
- 11 missing HTTP security headers → 8 remediated (February 1, 2026)
AI Operations Assistant (Added February 2026)
James (AI assistant via OpenClaw) provides 24/7 operational support:
- Receives Uptime Kuma alerts via webhook
- Runs and reviews vulnerability scans
- Applies security remediations
- Escalates to owner via Signal for critical issues
CC8: Change Management
| Control |
Status |
Evidence |
| CC8.1 Change process |
Implemented |
Staging environment, make deploy workflow |
| CC8.2 Pre-deployment testing |
Implemented |
18 integration tests, make check-db |
| CC8.3 Emergency changes |
Implemented |
Documented in IR plan |
CC9: Risk Mitigation
| Control |
Status |
Evidence |
| CC9.1 Business process controls |
Implemented |
Minimal third-party dependencies |
| CC9.2 Vendor management |
Implemented |
See Third-Party Services |
2. Availability
| Control |
Status |
Evidence |
| A1.1 Availability commitments |
Implemented |
99.9% SLA (excluding planned maintenance) |
| A1.2 Capacity planning |
Implemented |
Single-tenant; monitored via system metrics |
| A1.3 Recovery planning |
Implemented |
Disaster Recovery Plan |
Infrastructure Controls
| Control |
Implementation |
| Power redundancy |
UPS + natural gas generator (11-second failover) |
| Storage redundancy |
ZFS RAID-Z2 (2-drive fault tolerance) |
| Network redundancy |
1Gbit fiber primary + Starlink satellite backup |
| Backups |
Daily ZFS snapshots (30-day retention) + encrypted off-site |
| RTO |
4 hours |
| RPO |
24 hours |
Service Level Agreement
| Metric |
Commitment |
| Monthly uptime |
99.9% (excluding planned maintenance) |
| Unplanned downtime |
Maximum 43 minutes per month |
| Planned maintenance |
Excluded; 24-hour advance notice provided |
| Recovery time |
4 hours maximum |
| Data loss tolerance |
24 hours maximum |
Exclusions:
- Scheduled maintenance with advance notice
- Force majeure events
- User device/connectivity issues
- Third-party service failures outside inou control
3. Processing Integrity
| Control |
Status |
Evidence |
| PI1.1 Processing objectives |
Implemented |
API design documentation |
| PI1.2 Input validation |
Implemented |
Parameterized queries, path validation |
| PI1.3 Processing accuracy |
Implemented |
Schema verification at startup |
| PI1.4 Output completeness |
Implemented |
RBAC filtering |
| PI1.5 Error handling |
Implemented |
Structured error responses, logging |
Data Integrity Controls
| Control |
Implementation |
| SQL injection prevention |
Parameterized queries (? placeholders) |
| Schema enforcement |
Runtime validation via reflection |
| Transaction integrity |
SQLite ACID compliance |
4. Confidentiality
| Control |
Status |
Evidence |
| C1.1 Confidentiality requirements |
Implemented |
All PII encrypted at rest |
| C1.2 Data classification |
Implemented |
27 categories in lib/types.go |
Encryption Controls
| Layer |
Standard |
Implementation |
| Disk |
FDE |
Full disk encryption on all servers |
| Database |
AES-256-GCM |
Auto-encryption in db_queries.go |
| Transit |
TLS 1.3 |
All HTTPS connections |
| Tokens |
AES-256-GCM |
Encrypted with expiration |
| Compliance |
FIPS 140-3 |
Verified via make fips-check |
Data Retention
5. Privacy
| Principle |
Status |
Evidence |
| P1: Notice |
Implemented |
Privacy policy at /privacy-policy |
| P2: Choice/Consent |
Implemented |
Explicit consent, explicit grants |
| P3: Collection |
Implemented |
User-uploaded only |
| P4: Use/Retention/Disposal |
Implemented |
Data Retention Policy |
| P5: Access |
Implemented |
Self-service data export |
| P6: Third-party disclosure |
Implemented |
No sharing except legal orders |
| P7: Security |
Implemented |
FIPS 140-3 encryption |
| P8: Quality |
Implemented |
Self-service corrections |
Privacy Commitments
| Commitment |
Status |
| No advertiser sharing |
Implemented |
| No AI training use |
Implemented |
| No data sales |
Implemented |
| No third-party tracking |
Implemented |
| 30-day data request response |
Implemented |
Regulatory Compliance
| Regulation |
Status |
Evidence |
| HIPAA |
Implemented |
Encryption, access controls, audit logs |
| GDPR |
Implemented |
Export, deletion, consent, notification |
| FADP (Swiss) |
Implemented |
Same as GDPR |
| CCPA |
Implemented |
Disclosure, deletion, opt-out |
6. Physical Security
Facility Overview
| Attribute |
Description |
| Type |
Private secure facility |
| Access control |
Alarm system with monitoring |
| Power |
UPS + natural gas generator (11-second failover) |
| Connectivity |
1Gbit fiber + Starlink satellite backup |
| Physical access |
Restricted to owner |
Server Security
| Control |
Implementation |
| Full disk encryption |
All storage encrypted; data unreadable if hardware removed |
| Logical access |
SSH key-based only; password authentication disabled |
| Console access |
Headless servers; no KVM attached |
| Administrative access |
Single administrator (owner) |
Asset Disposal
Failed or decommissioned storage media is physically destroyed, rendering data unrecoverable. This exceeds NIST SP 800-88 requirements for media sanitization.
7. OS Hardening
Application Server (192.168.100.2)
| Control |
Status |
| Operating system |
Ubuntu 24.04.3 LTS |
| Automatic updates |
Enabled (unattended-upgrades, daily) |
| Firewall |
UFW active, default deny incoming |
| Intrusion prevention |
Fail2ban enabled (sshd jail) |
| SSH hardening |
Key-based only, password auth disabled |
| MAC enforcement |
AppArmor loaded, 9 profiles enforcing |
| Kernel hardening |
SYN cookies, RP filter, ASLR, ICMP restrictions |
Firewall Rules (Application Server)
| Port |
Rule |
| 22/tcp |
Allow from admin subnet (192.168.1.0/24) only |
| 443/tcp |
Allow (HTTPS) |
| 80/tcp |
Rate limited |
| 1080 |
Allow from reverse proxy (192.168.0.2) only |
Reverse Proxy (Caddy)
| Control |
Status |
| Operating system |
Ubuntu 24.04.3 LTS |
| Automatic updates |
Enabled |
| Firewall |
UFW active, default deny incoming |
| SSH |
Password auth disabled, rate limited |
| TLS |
Automatic HTTPS via ZeroSSL, TLS 1.2+ |
| Header |
Value |
| Strict-Transport-Security |
max-age=31536000; includeSubDomains; preload |
| X-Content-Type-Options |
nosniff |
| X-Frame-Options |
SAMEORIGIN |
| Referrer-Policy |
strict-origin-when-cross-origin |
| Permissions-Policy |
geolocation=(), microphone=(), camera=() |
| Cross-Origin-Opener-Policy |
same-origin-allow-popups |
| Cross-Origin-Resource-Policy |
same-origin |
| X-Permitted-Cross-Domain-Policies |
none |
Network Security (UDM-Pro)
| Control |
Implementation |
| VLAN isolation |
Production on VLAN 10 (192.168.100.0/24) |
| Firewall |
Zone-based, enabled |
| Inter-VLAN traffic |
Default deny; explicit allow for admin and proxy only |
| Firmware |
UniFi OS with auto-update |
8. Third-Party Services
Service Inventory
| Vendor |
Service |
Data Access |
Risk |
| Proton |
SMTP |
Verification codes only (6-digit numbers) |
Low |
| Openprovider |
DNS |
None |
None |
| Google |
Off-site backup storage |
Encrypted data only; cannot decrypt |
None |
Anthropic (Claude API)
| Attribute |
Detail |
| Service |
AI assistant via MCP integration |
| Data flow |
User-initiated queries; LLM pulls data from inou API |
| Data storage |
None; queries processed in real-time |
| BAA required |
No; user controls data flow, no PHI stored by vendor |
Rationale: The LLM integration is user-initiated. Users query their own data through their chosen AI tool. inou serves data via authenticated API; no PHI is stored or processed by Anthropic beyond the user's session.
9. Backup and Recovery
Backup Strategy
| Component |
Method |
Frequency |
Retention |
Location |
| Database |
ZFS snapshot |
Daily |
30 days |
Local (RAID-Z2) |
| Database |
rclone to cloud |
Daily |
90 days |
Google Drive (encrypted) |
| Images |
ZFS snapshot |
Daily |
30 days |
Local (RAID-Z2) |
| Images |
rclone to cloud |
Daily |
90 days |
Google Drive (encrypted) |
| Master key |
Manual |
On change |
Permanent |
Proton Pass (E2E encrypted) |
Encryption
- All data encrypted at rest before backup (AES-256-GCM)
- Off-site backups transmitted encrypted
- Google cannot decrypt backup contents
- Master key stored separately from data backups
Recovery Objectives
| Metric |
Target |
| RTO (Recovery Time Objective) |
4 hours |
| RPO (Recovery Point Objective) |
24 hours |
10. Action Items
Completed This Assessment (January 2026)
| Item |
Status |
| Incident Response Plan |
Created |
| Disaster Recovery Plan |
Created |
| Data Retention Policy |
Created |
| Risk Assessment |
Created |
| Security Policy |
Created |
| Physical security documentation |
Documented |
| Vendor assessment |
Documented |
| OS hardening documentation |
Documented |
Completed (February 2026)
| Item |
Status |
Date |
| External vulnerability scanning |
Nuclei from Zurich, automated |
Feb 1, 2026 |
| HTTP security headers |
8 headers added to Caddy |
Feb 1, 2026 |
| External availability monitoring |
Uptime Kuma from Zurich |
Feb 1, 2026 |
| Automated alerting |
Webhook → James AI → Signal |
Feb 1, 2026 |
| Weekly vulnerability scan |
Cron job (Sundays 10am ET) |
Feb 1, 2026 |
| Monthly vulnerability scan |
Cron job (1st, 9am ET) |
Feb 1, 2026 |
Recommended Actions
| Item |
Priority |
Target Date |
| Perform backup restore test |
P1 |
Q1 2026 |
Complete audit logging in lib/v2.go |
P2 |
Q1 2026 |
| Implement key rotation procedure |
P2 |
Q2 2026 |
| Add Content-Security-Policy header |
P2 |
Q1 2026 |
| Enable DNSSEC on inou.com |
P3 |
Q2 2026 |
| Evaluate cyber liability insurance |
P3 |
Q2 2026 |
11. Evidence Inventory
Policy Documents
| Document |
Location |
| Privacy Policy |
/privacy-policy |
| Security Page |
/security |
| Data Processing Agreement |
/legal/dpa |
| Incident Response Plan |
docs/incident-response-plan.md |
| Disaster Recovery Plan |
docs/disaster-recovery-plan.md |
| Data Retention Policy |
docs/data-retention-policy.md |
| Risk Assessment |
docs/risk-assessment.md |
| Security Policy |
docs/security-policy.md |
Technical Evidence
| Evidence |
Source |
| Encryption implementation |
lib/crypto.go |
| FIPS 140-3 compliance |
make fips-check |
| Access control |
lib/access.go, lib/v2.go |
| Database access controls |
lib/db_queries.go |
| Automated validation |
make check-db, make test |
| Network isolation |
VLAN 10 config, UDM-Pro firewall rules |
| Attack detection |
portal/tarpit.go |
12. Testing Summary
Automated Testing (Continuous)
| Test |
Frequency |
Coverage |
| Integration tests |
Per deploy |
Auth, data access, CRUD |
| DB access check |
Per deploy |
Blocks unauthorized patterns |
| FIPS validation |
Per deploy |
Cryptographic compliance |
| Schema verification |
Per startup |
Table/column integrity |
Manual Testing Schedule
| Test |
Frequency |
Last Performed |
Next Due |
| Backup restore |
Quarterly |
Not yet |
Q1 2026 |
| DR drill |
Annually |
Not yet |
Q4 2026 |
| Access review |
Quarterly |
January 2026 |
April 2026 |
| Penetration test |
Annually |
Not yet |
Q2 2026 |
Automated Security Testing
| Test |
Frequency |
Last Run |
Next Run |
| Nuclei full scan |
Monthly (1st) |
Jan 31, 2026 |
Feb 1, 2026 |
| Nuclei light scan |
Weekly (Sun) |
Feb 1, 2026 |
Feb 2, 2026 |
| Uptime monitoring |
Continuous |
Live |
Live |
13. Conclusion
Strengths
- Encryption: FIPS 140-3 compliant, AES-256-GCM at rest and in transit, full disk encryption
- Access control: RBAC enforced at data layer, single administrator, SSH key-only
- Infrastructure: Isolated VLAN, zone-based firewall, defense-in-depth
- Automation:
make check-db prevents security regressions
- Privacy: No third-party tracking, explicit user commitments
- Expertise: Owner has 20+ years enterprise data protection experience
Assessment Result
inou demonstrates comprehensive security controls appropriate for handling sensitive medical data. Technical controls meet or exceed SOC 2 requirements. Documentation has been completed as part of this assessment.
Recommendation: Proceed with formal SOC 2 Type II audit when business requirements warrant.
Appendix A: Regulatory Crosswalks
HIPAA Technical Safeguards
| HIPAA Requirement |
Control |
Status |
| 164.312(a)(1) Access Control |
CC6.1-6.4, RBAC |
Implemented |
| 164.312(a)(2)(iv) Encryption |
AES-256-GCM, FDE |
Implemented |
| 164.312(b) Audit Controls |
CC4.1, CC7.1-2 |
Implemented |
| 164.312(c)(1) Integrity |
PI1.2-1.5 |
Implemented |
| 164.312(d) Authentication |
CC6.2 |
Implemented |
| 164.312(e)(1) Transmission |
TLS 1.3 |
Implemented |
GDPR Article Mapping
| GDPR Article |
Control |
Status |
| Art. 5 (Principles) |
P1-P8 |
Implemented |
| Art. 15 (Access) |
P5, Export |
Implemented |
| Art. 17 (Erasure) |
P4, Deletion |
Implemented |
| Art. 32 (Security) |
CC5, CC6 |
Implemented |
| Art. 33 (Breach notification) |
IR Plan |
Implemented |
Appendix B: System Description
Overview
inou enables individuals to store, view, and analyze their medical data:
- Medical imaging (DICOM: MRI, CT, X-ray)
- Lab results and vitals
- Genome data
- Medical documents
Architecture
User --> HTTPS (TLS 1.3) --> Caddy Proxy --> Portal/API --> RBAC --> Encrypted SQLite
|
Audit Log
Components
| Component |
Technology |
Purpose |
| Portal |
Go, HTML |
Web interface |
| API |
Go, REST |
External access |
| Viewer |
Electron |
DICOM viewing |
| Database |
SQLite |
Encrypted storage |
| Proxy |
Caddy |
TLS termination, routing |
Infrastructure
| Environment |
Address |
Network |
| Production |
192.168.100.2 |
Isolated VLAN 10 |
| Staging |
192.168.1.253 |
Internal network |
Appendix C: Contact Information
Prepared By: Johan Jongsma, Founder & Owner
Assessment Date: January 25, 2026
Next Review: January 2027