SOC 2 Type II Self-Assessment Report
Organization: Dealspace (Muskepo B.V.)
Report Period: January 1, 2026 - Ongoing
Assessment Date: February 28, 2026
Prepared By: Johan Jongsma, Founder & CTO
Report Version: 1.0
Executive Summary
Dealspace is an M&A workflow platform providing secure deal management, document sharing, and collaboration for investment banks, advisors, and deal participants. 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. Formal SOC 2 Type II audit planned for Q4 2026.
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 |
Founder: 20+ years enterprise data protection, CTO Backup at Kaseya, founder of IASO Backup (acquired by SolarWinds/N-able) |
| CC1.5 Personnel accountability |
Implemented |
Automated enforcement via build validation; single admin access |
CC2: Communication and Information
| Control |
Status |
Evidence |
| CC2.1 Internal security info |
Implemented |
Security Policy, SECURITY-SPEC.md |
| CC2.2 Policy communication |
Implemented |
Policies in docs/ directory |
| CC2.3 External communication |
Implemented |
muskepo.com/privacy, muskepo.com/security |
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 |
Go build validation, integration tests |
| CC3.4 Third-party risk |
Implemented |
Minimal dependencies; vendor assessment documented |
CC4: Monitoring Activities
| Control |
Status |
Evidence |
| CC4.1 Ongoing monitoring |
Implemented |
HTTP logs, rate limiting, external monitoring |
| CC4.2 Remediation |
Implemented |
Incident Response Plan |
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, HKDF-SHA256, TLS 1.3 |
| CC5.3 Control deployment |
Implemented |
Data layer enforcement in Go application |
CC6: Logical and Physical Access
| Control |
Status |
Evidence |
| CC6.1 Logical access |
Implemented |
JWT auth, per-project encryption keys |
| CC6.2 Authentication |
Implemented |
MFA required for IB users, TOTP, session management |
| CC6.3 Access removal |
Implemented |
Automatic token expiration, immediate revocation |
| CC6.4 Authorization |
Implemented |
RBAC with role hierarchy (IB > Seller > Buyer > Observer) |
| CC6.5 Physical access |
Implemented |
Hosted at Hostkey Zürich data center; see Physical Security |
| CC6.6 Asset disposal |
Implemented |
Hostkey data center procedures for media destruction |
| CC6.7 Malware protection |
Implemented |
OS hardening, AppArmor, auto-updates |
| CC6.8 Infrastructure security |
Implemented |
UFW firewall, SSH key-only, default-deny rules |
CC7: System Operations
| Control |
Status |
Evidence |
| CC7.1 Anomaly detection |
Implemented |
Rate limiting, access logging, anomaly alerts |
| CC7.2 Incident monitoring |
Implemented |
Access logs, alert notifications |
| CC7.3 Incident response |
Implemented |
Incident Response Plan |
| CC7.4 Recovery |
Implemented |
Disaster Recovery Plan |
CC8: Change Management
| Control |
Status |
Evidence |
| CC8.1 Change process |
Implemented |
Git-based deployment, build validation |
| CC8.2 Pre-deployment testing |
Implemented |
Integration tests, schema validation |
| 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 |
Monitored via system metrics |
| A1.3 Recovery planning |
Implemented |
Disaster Recovery Plan |
Infrastructure Controls
| Control |
Implementation |
| Hosting |
Hostkey VPS, Zürich, Switzerland |
| Server |
Single VPS (82.24.174.112) |
| Backups |
Daily SQLite backups, 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 |
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 per role |
| PI1.5 Error handling |
Implemented |
Structured error responses, logging |
Data Integrity Controls
| Control |
Implementation |
| SQL injection prevention |
Parameterized queries |
| Schema enforcement |
Runtime validation |
| Transaction integrity |
SQLite ACID compliance |
| Concurrency |
Optimistic locking with version fields |
4. Confidentiality
| Control |
Status |
Evidence |
| C1.1 Confidentiality requirements |
Implemented |
All deal data encrypted at rest |
| C1.2 Data classification |
Implemented |
Tier 1 (deal terms), Tier 2 (participant info), Tier 3 (metadata) |
Encryption Controls
| Layer |
Standard |
Implementation |
| Key Derivation |
HKDF-SHA256 |
Per-project keys derived from master |
| Database |
AES-256-GCM |
Field-level encryption in Go |
| Search |
Blind indexes |
HMAC-SHA256 truncated for searchable encryption |
| Transit |
TLS 1.3 |
All HTTPS connections via Caddy |
| Compliance |
FIPS 140-3 |
BoringCrypto module |
Data Retention
5. Privacy
| Principle |
Status |
Evidence |
| P1: Notice |
Implemented |
Privacy policy at muskepo.com/privacy |
| P2: Choice/Consent |
Implemented |
Explicit consent, explicit grants |
| P3: Collection |
Implemented |
User/organization-provided 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 |
| GDPR |
Implemented |
Export, deletion, consent, notification |
| FADP (Swiss) |
Implemented |
Same as GDPR |
| CCPA |
Implemented |
Disclosure, deletion, opt-out |
6. Physical Security
Infrastructure Overview
| Attribute |
Description |
| Provider |
Hostkey (Shannon Network) |
| Location |
Zürich, Switzerland |
| Server |
VPS at 82.24.174.112 |
| Data center |
FADP/GDPR compliant facility |
| Physical access |
Managed by Hostkey |
Server Security
| Control |
Implementation |
| Disk encryption |
Full disk encryption on VPS |
| Logical access |
SSH key-based only; password authentication disabled |
| Administrative access |
Single administrator (founder) |
7. OS Hardening
Application Server (82.24.174.112)
| Control |
Status |
| Operating system |
Ubuntu 24.04 LTS |
| Automatic updates |
Enabled (unattended-upgrades, daily) |
| Firewall |
UFW active, default deny incoming |
| SSH hardening |
Key-based only, password auth disabled |
| MAC enforcement |
AppArmor loaded |
| Kernel hardening |
SYN cookies, RP filter, ASLR |
Firewall Rules
| Port |
Rule |
| 22/tcp |
Allow (SSH, key-only) |
| 443/tcp |
Allow (HTTPS via Caddy) |
| 80/tcp |
Allow (redirect to HTTPS) |
| 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=() |
8. Third-Party Services
Service Inventory
| Vendor |
Service |
Data Access |
Risk |
| Hostkey |
VPS hosting |
Encrypted data on disk |
Low (FADP compliant) |
| Let's Encrypt |
TLS certificates |
None |
None |
Minimal Dependency Architecture
Dealspace is designed with minimal external dependencies:
- Single Go binary
- SQLite database
- Caddy reverse proxy
- No external SaaS integrations required
9. Backup and Recovery
Backup Strategy
| Component |
Method |
Frequency |
Retention |
Location |
| Database |
SQLite backup |
Daily |
30 days |
Encrypted off-site |
| Master key |
Manual |
On change |
Permanent |
Separate secure storage |
Encryption
- All data encrypted at rest before backup (AES-256-GCM)
- Backups transmitted encrypted
- 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 (February 2026)
| Item |
Status |
| Security architecture specification |
Created (SECURITY-SPEC.md) |
| Incident Response Plan |
Created |
| Disaster Recovery Plan |
Created |
| Data Retention Policy |
Created |
| Risk Assessment |
Created |
| Security Policy |
Created |
| Self-Assessment |
Completed |
Recommended Actions
| Item |
Priority |
Target Date |
| Perform backup restore test |
P1 |
Q1 2026 |
| Complete audit logging |
P2 |
Q1 2026 |
| Implement key rotation procedure |
P2 |
Q2 2026 |
| External penetration test |
P2 |
Q2 2026 |
| Formal SOC 2 Type II audit |
P1 |
Q4 2026 |
11. Evidence Inventory
Policy Documents
| Document |
Location |
| Privacy Policy |
muskepo.com/privacy |
| Security Page |
muskepo.com/security |
| Terms of Service |
muskepo.com/terms |
| Data Processing Agreement |
muskepo.com/dpa |
| Incident Response Plan |
docs/soc2/incident-response-plan.md |
| Disaster Recovery Plan |
docs/soc2/disaster-recovery-plan.md |
| Data Retention Policy |
docs/soc2/data-retention-policy.md |
| Risk Assessment |
docs/soc2/risk-assessment.md |
| Security Policy |
docs/soc2/security-policy.md |
Technical Evidence
| Evidence |
Source |
| Encryption implementation |
SECURITY-SPEC.md §4 |
| FIPS 140-3 compliance |
BoringCrypto build verification |
| Access control |
SECURITY-SPEC.md §3 |
| Rate limiting |
SECURITY-SPEC.md §8 |
| Audit logging |
SECURITY-SPEC.md §9 |
12. Testing Summary
Automated Testing (Continuous)
| Test |
Frequency |
Coverage |
| Integration tests |
Per deploy |
Auth, data access, CRUD |
| Schema verification |
Per startup |
Table/column integrity |
| Build validation |
Per deploy |
Cryptographic compliance |
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 |
February 2026 |
May 2026 |
| Penetration test |
Annually |
Not yet |
Q2 2026 |
13. Conclusion
Strengths
- Encryption: FIPS 140-3 compliant (BoringCrypto), AES-256-GCM at rest, per-project key derivation via HKDF-SHA256
- Access control: RBAC enforced at data layer, role hierarchy, MFA for IB users
- Infrastructure: Single binary, minimal attack surface, Swiss data jurisdiction
- Privacy: No tracking, no data sales, clear retention policies
- Expertise: Founder has 20+ years enterprise data protection experience
Assessment Result
Dealspace demonstrates comprehensive security controls appropriate for handling confidential M&A transaction data. Technical controls meet or exceed SOC 2 requirements.
Status: Self-Assessment Complete
Recommendation: Proceed with formal SOC 2 Type II audit in Q4 2026
Appendix A: Regulatory Crosswalks
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
Dealspace enables investment banks, sellers, and buyers to manage M&A transactions:
- Deal workflow management (requests, responses, routing)
- Secure document sharing with dynamic watermarking
- Access-controlled data rooms
- Real-time collaboration
Architecture
Client --> HTTPS (TLS 1.3) --> Caddy Proxy --> Go Binary --> RBAC --> Encrypted SQLite
|
Audit Log
Components
| Component |
Technology |
Purpose |
| Application |
Go binary |
API and business logic |
| Database |
SQLite |
Encrypted storage |
| Proxy |
Caddy |
TLS termination, HTTPS |
| Hosting |
Hostkey VPS |
Zürich, Switzerland |
Infrastructure
| Environment |
Address |
Location |
| Production |
82.24.174.112 |
Zürich, Switzerland |
Appendix C: Contact Information
Prepared By: Johan Jongsma, Founder & CTO
Assessment Date: February 28, 2026
Next Review: February 2027
This is a self-assessment document. Formal SOC 2 Type II audit planned for Q4 2026.