Back to SOC 2
Security Policy
Version: 1.0 Effective: February 2026 Owner: Johan Jongsma Review: Annually
1. Purpose
Establish security requirements for CogniSuite systems, data, and operations.
2. Scope
- All CogniSuite systems (production)
- All M&A deal data processed by CogniSuite
- All administrative access
3. Roles and Responsibilities
| Role | Responsibilities |
|---|---|
| Owner (Johan Jongsma) | Security policy, incident response, system administration, compliance |
4. Access Control
4.1 Administrative Access
| System | Method | Requirements |
|---|---|---|
| Production server | SSH | Ed25519 key only |
| Database | Local only | No remote connections |
| Master key | Secure storage | Separate from data |
4.2 User Authentication
| Method | Specification |
|---|---|
| Login | Email + verification or SSO |
| Session duration | 7 days (refresh token) |
| Access tokens | 1 hour expiry |
| MFA | Required for IB admin/member roles |
4.3 Principle of Least Privilege
- Users access only their assigned projects by default
- Explicit invitations required for project access
- RBAC enforced at data layer
- Role hierarchy: IB Admin > IB Member > Seller Admin > Seller Member > Buyer Admin > Buyer Member > Observer
5. Data Protection
5.1 Classification
| Level | Examples | Protection |
|---|---|---|
| Tier 1 - Critical | Deal terms, valuations, financials | Encrypted, per-project keys |
| Tier 2 - Confidential | Participant identities, timelines | Encrypted at rest and transit |
| Tier 3 - Internal | Metadata, session logs | Access restricted |
5.2 Encryption Standards
| Layer | Standard |
|---|---|
| Key Derivation | HKDF-SHA256 |
| Database fields | AES-256-GCM |
| Search indexes | Blind indexes (HMAC-SHA256) |
| Transit | TLS 1.3 |
| Compliance | FIPS 140-3 (BoringCrypto) |
5.3 Key Management
| Key | Storage | Backup |
|---|---|---|
| Master key | Secure file (chmod 600) | Separate secure storage |
| TLS certificates | Caddy auto-managed | Let's Encrypt renewal |
| SSH keys | ~/.ssh/ | Local backup |
| Per-project keys | Derived via HKDF | Not stored (derivable) |
6. Infrastructure Security
6.1 Architecture
| Component | Location | Purpose |
|---|---|---|
| Production | 82.24.174.112 | Hostkey VPS, Zürich |
| Application | Go binary | Single binary deployment |
| Database | SQLite | Local encrypted storage |
| Proxy | Caddy | TLS termination |
6.2 Firewall Policy
Default: Deny all incoming
| Port | Source | Purpose |
|---|---|---|
| 22/tcp | Any (key-only) | SSH |
| 443/tcp | Any | HTTPS |
| 80/tcp | Any | Redirect to HTTPS |
6.3 OS Hardening
| Control | Implementation |
|---|---|
| Operating system | Ubuntu 24.04 LTS |
| Updates | Automatic (unattended-upgrades) |
| Firewall | UFW, default deny |
| SSH | Key-only, password disabled |
| MAC | AppArmor enforcing |
| Kernel | SYN cookies, RP filter, ASLR |
7. Application Security
7.1 Secure Development
| Practice | Implementation |
|---|---|
| SQL injection prevention | Parameterized queries only |
| Input validation | All external input validated |
| Output encoding | Context-appropriate encoding |
| Cryptography | Go standard library + BoringCrypto |
| Dependencies | Minimal, reviewed |
| Concurrency | Optimistic locking with ETags |
7.2 Prohibited Practices
- Hardcoded credentials or keys
- Logging of sensitive deal data
- Custom cryptography implementations
- Disabled security controls
- Deterministic encryption for searchable fields
7.3 Deployment Security
| Control | Implementation |
|---|---|
| Build validation | go build with boringcrypto |
| Testing | Integration tests |
| Rollback | Previous binary available |
8. Physical Security
8.1 Data Center (Hostkey Zürich)
| Control | Implementation |
|---|---|
| Location | Zürich, Switzerland |
| Compliance | FADP, GDPR compliant |
| Physical access | Managed by Hostkey |
| Jurisdiction | Swiss data protection law |
8.2 Server Security
| Control | Implementation |
|---|---|
| Disk encryption | Full disk encryption |
| Physical access | Hostkey managed |
| Console | SSH only |
9. Incident Response
Contact: security@cognisuite.ai
Severity Classification
| Severity | Response Time |
|---|---|
| Critical | < 1 hour |
| High | < 4 hours |
| Medium | < 24 hours |
| Low | < 72 hours |
10. Business Continuity
| Metric | Target |
|---|---|
| RTO | 4 hours |
| RPO | 24 hours |
| SLA | 99.9% (excluding maintenance) |
11. Compliance
Regulatory Framework
| Regulation | Applicability |
|---|---|
| GDPR | EU residents |
| FADP | Swiss residents |
| CCPA | California residents |
Audit Requirements
- Maintain audit logs for 7 years
- Annual security review
- Document all security incidents
12. Third-Party Services
| Vendor | Service | Data Exposure | Controls |
|---|---|---|---|
| Hostkey | VPS hosting | Encrypted data | FADP compliant |
| Let's Encrypt | TLS certs | None | N/A |
13. Monitoring and Logging
Logged Events
| Event | Retention |
|---|---|
| HTTP requests | 90 days |
| Authentication | 90 days |
| Data access | 7 years |
| Security events | 7 years |
Alerting
| Event | Alert Method |
|---|---|
| Failed logins | Rate limiting |
| Anomalous access | Anomaly detection |
| Service outage | Monitoring alert |
14. Vulnerability Management
Remediation SLAs
| Severity | Response | Resolution |
|---|---|---|
| Critical | 4 hours | 24 hours |
| High | 24 hours | 7 days |
| Medium | 7 days | 30 days |
| Low | 30 days | 90 days |
15. Policy Maintenance
Review Schedule
| Review | Frequency |
|---|---|
| Full policy review | Annually |
| Risk assessment | Annually |
| Incident review | After each incident |
| Control testing | Quarterly |
Change Management
Policy changes require: 1. Risk assessment of change 2. Documentation update 3. Version increment 4. Effective date notation
Document end