Cybersecurity Policy

Warren Davis Data Systems, LLC, a Delaware limited liability company — operator of Warren, a market-data and analysis terminal for investment professionals.

Purpose and posture

Warren's product thesis is that a financial figure is only useful if its origin can be established. The same standard governs this policy: it states what is actually implemented and enforced, not what is aspired to. Where a control is absent, this document says so rather than implying otherwise. Every technical control described below is enforced in code and covered by an automated test that fails if it regresses; the security-critical ones are additionally mutation tested — the defect is deliberately reintroduced and a test confirmed to catch it — so the controls are demonstrated rather than asserted.

Warren does not take custody of client assets, does not hold client funds, and is not an order-routing intermediary. The client's broker executes; Warren informs and submits at the client's direction.

0 · Scope, and the division of responsibility

This section defines the boundary of what Warren Davis Data Systems, LLC is responsible for. It is stated first because most security failures in connected financial software occur at a boundary that was never written down.

0.1 What is in scope. The Warren application, its production infrastructure, the data it stores, the corporate devices used to administer it, and the vendors listed in §7.

0.2 What is expressly out of scope.

• The client's brokerage account and its security. That relationship is

between the client and their broker. Warren does not open, maintain, or control brokerage accounts.

• The client's own credentials and devices, including their brokerage

password, second factor, workstation and network. Warren never requests, receives, or possesses a client's brokerage password or second factor — connection is made by the client authenticating directly with their own broker. This is an architectural property, not a policy promise.

• Execution, settlement, custody and the accuracy of broker-supplied data.

These are the broker's, and are governed by the client's agreement with them.

• Third-party market data content. Warren transmits each figure with its

stated source; correctness at source is the source's.

0.3 Client responsibilities. Clients are responsible for maintaining the confidentiality of their Warren credentials, for the security of the devices from which they access it, for promptly notifying us of any suspected compromise, for revoking a brokerage connection they no longer intend to use, and for reviewing any order before authorising it. Warren presents information and submits instructions; every trading decision is the client's.

0.4 Status of this document. This is a statement of the security practices in effect at the stated date. It is not a warranty, guarantee, or contractual undertaking, and it does not vary the terms of any agreement between the parties. Practices evolve; this document is reviewed at least annually and may be updated. Where this document and an executed agreement differ, the agreement governs.

1 · Data Classification and Handling

Data is handled in four classes.

1.1 Secrets — brokerage credentials, API keys, OAuth client secrets, session signing material, step-up credentials. *Never* returned by an API response, written to a log, or rendered in any interface. Stored encrypted (§3). Displayed only as a mask computed at write time; the read path never decrypts for display. Automated tests assert that no response body contains key-shaped material.

1.2 Client account data — positions, balances, orders, and any data retrieved from a connected brokerage on the client's behalf. Scoped to the account holder and to administrators of that client's own firm. Never pooled across clients, never used to train models, never resold or redistributed. Cached only under a key containing both firm and owner identifiers.

1.3 Operational and personal data — accounts, roles, invitations, audit records, support correspondence. Access is role-scoped and least-privilege (§2). Administrative action against it is recorded in an append-only audit log naming the human who authorised it.

1.4 Market and reference data — third-party and public market data. Carries redistribution rights as a typed property with three values, where "not established" is treated as not permitted. The system will decline to serve data whose licence has not been established rather than assume permission.

Handling rules. Secrets are never transmitted to a third party other than the issuing venue. No client data is placed in URL parameters or query strings. Data is not copied to personal devices or unmanaged storage.

2 · Access Control and Privileged Access Management

2.1 Product access is invitation-only and fails closed. Registration requires a single-use, expiring, CSPRNG-generated token bound to the invited address, redeemed atomically and rate-limited by source IP. Social sign-in providers are configured with implicit sign-up disabled, so authenticating with Google, Microsoft, GitHub or Apple can sign an existing member in but cannot create an account. A test discovers the configured providers by reading the source and fails if any provider lacks that flag.

2.2 Tenancy isolation fails closed. Every query is scoped by firm and owner through a single facade. An unusable or absent scope resolves to an impossible filter that matches nothing, never to an unfiltered query. Tests assert on the generated filter rather than on returned rows, because a widened filter still returns correct-looking data in a small dataset.

2.3 Administrative surface. The administrative interface is served only on a dedicated hostname; on every other hostname the administrative path tree returns 404 rather than a redirect, so its existence is not disclosed. Administrative capability is role-scoped, and the set of administrative sections is derived from a single catalogue rather than maintained by hand.

2.4 Step-up authorisation for consequential action. Administrative actions that touch money or access require a step-up credential held in a separate store, hashed with scrypt, single-use, scoped to one action, and short-lived. Possession of a session is not sufficient authority for these actions.

2.5 Machine and agent access. Automated assistants operating within the product act on the authenticated operator's own request, carrying that operator's identity; they hold no service account and no standing authority. Actions that write, send, spend or revoke require explicit on-screen authorisation from the operator. A spoken confirmation authorises nothing — authority is established through the interface, not through a transcript.

2.6 Infrastructure access. Production infrastructure is administered through the hosting provider's authenticated CLI and console, restricted to the personnel listed as authorised persons. Multi-factor authentication is required on every account that can reach production or the source of truth — the hosting provider (Fly.io), the DNS provider (Cloudflare), the source repository (GitHub), and the email account used to recover any of them. The database is operated by Warren on the hosting provider's private network and is not exposed to the public internet (§3.2), so it has no separate console account.

2.7 Joiners and leavers. Access is provisioned and revoked by the document owner. Warren Davis Data Systems presently has one authorised person, so there is no standing shared credential and no dormant account to reclaim. Before any additional person is granted production access, that grant and its revocation date are recorded in writing, and revocation includes rotating any secret that person could have read. We state the size of the company plainly rather than implying a segregation of duties we do not have.

3 · Encryption of Data at Rest and in Transit

3.1 At rest — application layer. Brokerage credentials and API secrets are sealed with AES-256-GCM, per record, with a random 96-bit initialisation vector. GCM authenticates the ciphertext, so tampering is detected on decryption rather than yielding a plausible value. Admin integration secrets are sealed under a separate key domain and additionally bind the field name as additional authenticated data, so such a value cannot be relocated into another field's slot. This has been verified adversarially: reading the raw database document shows no plaintext and no value field, and decryption fails with the database URI or any guessed passphrase. A database backup alone is inert. Encryption keys are held as platform secrets, never in the repository, and are not retrievable through the deployment tooling — only their digests are visible.

3.2 At rest — storage layer. Application data is held in MongoDB 7, operated by Warren on a Fly.io machine in the iad region, on a provider- encrypted persistent volume. The database listens only on the hosting provider's private IPv6 network (.internal); it has no public address and no public listener, and is reachable only from our own application instances.

We do not use a managed database service. That is stated because it changes what a reviewer should expect from §5.4: the recovery guarantees below are the provider's volume snapshots, not a managed service's point-in-time restore.

3.3 In transit. All public traffic is HTTPS with TLS terminated at the edge. HSTS is enforced — verified live: strict-transport-security: max-age=63072000; includeSubDomains. Connections to third-party venues and data sources are TLS. Internal service-to-service traffic runs over the provider's private network.

3.4 Security headers. Enforced on every production response and verified live:

strict-transport-security: max-age=63072000; includeSubDomains x-frame-options: SAMEORIGIN x-content-type-options: nosniff referrer-policy: strict-origin-when-cross-origin content-security-policy: frame-ancestors 'self'; base-uri 'self'; object-src 'none'; form-action 'self' permissions-policy: camera=(), geolocation=(), payment=(), usb=(), … (deny by default)

4 · Vulnerability Management and Patch Management

4.1 Immutable production. Production runs as immutable container images on Firecracker microVMs. There is no interactive shell in the serving path and no in-place mutation: patching is a redeploy that replaces the machine rather than modifying it. Consequently there are no long-lived servers accumulating state, drift or malware, and rollback is selecting a prior release.

4.2 Dependencies. Installed from a committed lockfile, so builds are reproducible and dependency changes are visible in version control. Images are content-addressed by digest. Base images are updated by rebuilding on a current base.

4.3 Static verification on every change. Type checking across the codebase and a suite of 13,000+ automated tests, including tests that specifically pin security properties — tenancy filters, order authorisation, credential masking, sign-up gating, administrative host isolation. Security-critical guards are mutation tested.

4.4 Reporting. Security concerns may be reported to security@warrendavisdata.com. We aim to acknowledge a report within two business days. That is a target we can meet at our present size, stated in preference to a shorter one we could not. Reports are read by the document owner.

We do not currently operate a paid bug bounty. A good-faith report made without exfiltrating data, degrading service or accessing another client's information will not be met with legal action from us.

4.5 Stated honestly: there is no formal third-party penetration test or automated dependency-scanning pipeline in place at this time. Both are on the roadmap and neither is claimed anywhere in our public material.

5 · Incident Response and Disaster Recovery

5.1 Roles. The document owner — Paul Krzemuski, Chief Executive Officer — is the incident owner, and is accountable for declaring an incident, running the sequence below, and signing the post-incident record. There is no separate on-call rotation; at our present size, naming one would be a fiction.

5.2 Response sequence. 1. Contain — revoke affected credentials and sessions; if a brokerage credential is implicated, disconnect the affected venue connections. 2. Assess — establish scope from the append-only audit log and provider logs. 3. Notify — affected clients, and any venue whose credentials or data are implicated, including Alpaca, without undue delay and in any case within 72 hours of confirming an incident that affects client data. 4. Remediate — deploy a fix as a new immutable release; rotate all potentially exposed secrets. 5. Review — written post-incident record, and a test added that fails if the defect recurs. This is existing engineering practice, not an aspiration.

5.3 Credential compromise. Because credentials are sealed with a key held outside the database (§3.1), exposure of database contents alone does not expose credentials. Key rotation invalidates all sealed values, requiring reconnection — a deliberate trade in favour of containment.

5.4 Recovery. The application itself is stateless and rebuilt from version control; recovering the application is a redeploy of an immutable release.

Application state is on a single Fly.io persistent volume, protected by the provider's automatic daily volume snapshots with a five-day retention window. Snapshots are encrypted and stored by the provider separately from the volume.

Stated plainly, because a reviewer will ask and should not have to:

Adding a replica set and shortening the recovery point are on the roadmap and are not claimed as present controls. No client assets or funds are held (§5.5), so the consequence of this window is loss of our own analytical state, not of a client's money or positions.

5.5 Business continuity. No client assets or funds are held, so a Warren outage does not impede a client's access to their own brokerage account or positions. Clients retain their direct brokerage relationship at all times.

6 · Physical Security

Warren operates no offices, data centres or physical infrastructure of its own. Production is hosted by Fly.io, which operates in audited third-party facilities.

Corporate devices. Production is administered from a company-controlled macOS workstation with full-disk encryption (FileVault) enabled, current operating-system security updates, an enforced screen lock, and multi-factor authentication on every account that can reach production.

We do not operate mobile device management or a managed-endpoint fleet, and do not claim to. With one authorised person and one workstation, an MDM estate would be a control described rather than a control exercised.

7 · Vendor Risk Management

7.1 Principle. Vendors are selected for the minimum access needed, and no vendor is given standing access to client brokerage credentials.

7.2 Material vendors.

7.3 Model and AI vendors. Model inference is used for analysis and conversation. Client brokerage credentials are never placed in a model context. System components that read account data for an operator call the application's own permission-checked interfaces rather than the datastore directly, precisely so that redaction applied at that layer is not bypassed. Client data is not used to train third-party models.

7.4 Review. Vendors are reviewed on addition and at the annual review of this policy. A vendor's own security posture and certifications are considered at selection.

8 · Assurance, certification and compensating controls

Warren's assurance model is verification in code rather than attestation on paper. Each control in this policy is enforced by an automated test that fails if it regresses, and the security-critical ones are additionally mutation tested. This is stated precisely so a counterparty can assess it accurately; an inflated security claim is itself a security risk, because it causes a counterparty to extend trust the system has not earned.

Proportionality. The controls described here are proportionate to a company of this size operating a product that holds no client assets, holds no client funds, takes no custody, and never possesses a client's brokerage password or second factor. Where a control common at larger firms is absent, the table above names it and names what stands in its place.

Availability of evidence. Any control in this document can be demonstrated on request, including a walkthrough of the enforcing code and its tests. We would rather a counterparty find a problem now than a client find it later.

9 · Governance

Ownership. The document owner named at the head of this policy is accountable for its maintenance, for incident response (§5), and for provisioning and revoking access (§2).

Review. At least annually, and on any material change to architecture, vendors, or the regulatory position.

Exceptions. Any deviation from this policy must be recorded in writing by the document owner, with the compensating control and a review date. Undocumented exceptions are not permitted.

Personnel. All personnel with production access are bound by these requirements. Where personnel other than the document owner are engaged, acceptance of this policy is a condition of production access and is recorded at onboarding.

Change record.

Approved by: Paul Krzemuski, Chief Executive Officer, Warren Davis Data Systems, LLC — 24 August 2026

*Warren Davis Data Systems. This document contains information about security controls and is shared in confidence for the purpose of counterparty due diligence.*