Information Security Policy [DRAFT]

STATUS: DRAFT v1.0 — pending legal counsel review.

Operative for internal use; [DRAFT] will be removed once counsel sign-off is recorded.

Owner: Keel — Fund Manager (policy-level); Engineering Owner (operational execution)

Effective: 2026-05-27 (interim; final effective date confirmed at counsel sign-off)

Review cadence: Annual (next review by 2027-05-27); ad-hoc on material platform changes

Applies to: All systems, data, vendors, and personnel involved in operating the Keel fund management platform.

1. Purpose and Scope

This policy is the firm's master statement of how we protect the confidentiality, integrity, and availability of fund and limited-partner data. It is the umbrella document beneath which the firm's other security policies sit:

• Patch SLA Policy — patch-sla.md
• EOL Software Management Policy — eol-software.md
• Access Control Policy — access-control.md
• Privacy Policy (public-facing) — privacy-policy.md
• Data Retention and Deletion Policy — pending

This policy applies to all systems and data that constitute the platform, including the production application, staging environments, all hosting and storage vendors, all third-party integrations, and all human and service accounts with access.

2. Data Classification

We classify data into four tiers. Controls scale with sensitivity.

Every persisted field in the application schema is implicitly classified by its containing model (Investor data → Restricted/Confidential; CapitalCall → Confidential; Prospect → Internal; FundDocument → varies by visibility setting).

3. Secure Development

The platform is developed and deployed under the following practices:

1. Source control: all code is maintained in a private GitHub repository. Direct pushes to main are restricted; all production changes flow through staging first.

2. Dependency management: every dependency is declared in package.json with a resolved version in package-lock.json. Dependabot scans the dependency tree weekly and on push (see Patch SLA Policy § 3).

3. Vulnerability scanning: automated via GitHub Dependabot security advisories and platform-wide GitHub Advisory Database alerts. Patches deployed under the timelines defined in the Patch SLA Policy.

4. Static analysis: TypeScript strict mode catches a meaningful class of correctness issues at build time. ESLint covers stylistic and known-pitfall issues.

5. Schema migrations: Prisma migrations are reviewed before being applied. Migrations that drop columns or destroy data go through --accept-data-loss only with explicit Fund Manager approval (see § 7 — Schema-change runbook to be added in Institutional Readiness work).

6. Pre-release checks: every Vercel deployment runs prisma generate, TypeScript compile, and next build. Build failures block deploy.

7. Code review: material changes to authentication, authorization, or audit-logging require explicit code review and a written justification in the commit message.

4. Cryptography

• In transit: TLS 1.2+ for all client–server traffic. HTTP requests are redirected to HTTPS by the Vercel edge.
• At rest: database encryption provided by Neon (AES-256, AWS-managed keys). File storage encryption provided by Vercel Blob.
• Application-level secrets: stored as Vercel environment variables; injected at runtime; never committed to the repository. Rotation cadence is at least annual and on every personnel change with access.
• Authentication tokens: NextAuth JWT signed with a per-environment secret. Magic-link tokens are single-use, time-bound, and stored only hashed once consumed.
• Sensitive identifiers (planned): SSN/EIN and bank-account numbers are currently stored unencrypted at the application layer (relying on at-rest disk encryption only). Application-layer column encryption is on the Plaid attestation roadmap and the institutional-readiness backlog.

5. Authentication and Access

See the dedicated Access Control Policy (access-control.md) for full detail. Summary:

• All accounts are role-scoped via prisma/schema.prisma UserRole enum.
• Mutating actions write AuditEvent rows via src/lib/audit.ts.
• Quarterly access reviews are produced and signed by the Fund Manager.
• MFA is required on platform-administrator consoles (Vercel, Neon, GitHub, Resend). MFA on the in-app admin login is on the roadmap (Plaid attestation item C11).

6. Incident Response

When a security incident is detected (unauthorized access, data exposure, ransomware indicator, vendor breach affecting our data):

1. Triage (within 4 hours of detection): the engineering owner records the incident in the engineering log with: discovery time and method, suspected scope, affected data tiers, immediate containment actions.

2. Contain (within 24 hours): block the attack vector (rotate credentials, disable affected accounts, isolate affected components), preserve evidence, notify the Fund Manager.

3. Eradicate and recover: remove the cause, patch the vulnerability, restore from clean backups if needed, verify integrity, return services to normal operation.

4. Communicate: if LP data is materially affected, notify affected LPs within 72 hours of confirmed exposure and outline the impact, our response, and recommended LP actions. Notify Plaid within 72 hours if Plaid-integration data is involved.

5. Post-incident review (within 14 days): document the incident in full, identify root cause and contributing factors, capture corrective actions and their owners, update relevant policies if process gaps are identified.

An incident response playbook with named runbooks for the most likely categories (credential compromise, dependency vulnerability exploitation, third-party vendor breach) will be added as a dedicated runbooks directory.

7. Vendor Management

Every third-party vendor that processes restricted or confidential data is selected and reviewed against the following criteria:

• Security posture: published SOC 2 Type II report or equivalent independent assessment, where available.
• Data processing agreement: written agreement specifying the vendor's data handling obligations, breach notification timelines, sub-processor controls, and termination data-deletion commitments.
• Necessity: data shared is the minimum needed for the vendor's function. Production-grade access to copy data into long-term vendor stores is avoided in favor of on-demand access scoped to the function.

Current vendors are listed in the Privacy Policy § 4 and in the firm's internal vendor inventory. The Fund Manager reviews the vendor list annually.

8. Personnel

The firm operates with a small core team (Fund Manager + Engineering Owner) plus engaged third parties (legal counsel, accountants, advisors). Each person with access:

• Acknowledges this policy on the date of access grant.
• Completes a brief security-awareness review annually, covering phishing, credential hygiene, and data-classification basics.
• Operates under the Access Control Policy with respect to off-boarding when access is no longer required.

9. Physical Security

The platform is cloud-hosted. Physical security of the underlying infrastructure is the responsibility of our hosting vendors (Vercel, Neon). We rely on the vendors' published certifications and do not maintain firm-controlled physical infrastructure.

Personnel devices (laptops, mobile devices) used to access the platform must:

• Have full-disk encryption enabled.
• Auto-lock after 5 minutes of inactivity.
• Be patched in line with vendor recommendations.
• Be promptly reported if lost or stolen, triggering credential rotation for accounts that may have been accessible from the device.

10. Business Continuity and Disaster Recovery

• Database: Neon provides point-in-time recovery (PITR) on paid plans. Verify the firm's Neon plan supports PITR for both the staging and production projects (the staging DB split documented 2026-05-22 uses separate Neon projects).
• File storage: Vercel Blob retention is configured for both staging and production stores.
• Code: GitHub holds the canonical repository plus all branches. A local working tree is maintained by the engineering owner.
• Configuration: Vercel environment variables are documented and recoverable from the platform.
• Restore drills: a documented restore procedure and at least one annual restore drill are on the institutional-readiness backlog and will be formalized in a dedicated runbook.

Recovery objectives:

11. Compliance and Continuous Improvement

This policy is reviewed annually. Material updates require Fund Manager approval. Significant platform changes (new third-party vendor, new authentication method, schema migration affecting Restricted data) trigger an ad-hoc review of the relevant sections of this policy and its child policies.

Annual review is supported by a quarterly AI-assisted drift check that compares the policy text against the current code and configuration state. The engineering owner reviews drift reports and either updates the policy or remediates the drift.

12. Document Hierarchy

Information Security Policy   (this document; master)
├── Patch SLA Policy
├── EOL Software Management Policy
├── Access Control Policy
├── Privacy Policy           (public-facing)
└── Data Retention and Deletion Policy   (pending)

The master policy governs in cases of conflict, but each child policy controls within its specific subject matter.

Change history

• 2026-05-27 — Initial version (v1.0). Authored alongside Plaid attestation work; serves as the umbrella for all child security policies in the firm.