Cybersecurity Policy

Version 1.0 · Effective: October 14, 2026 · Next review: October 2027

This policy describes how UnderForest LLC, doing business as TradingMixer ("TradingMixer," "we," "us," or "our"), protects the TradingMixer app and the information entrusted to it. It applies to all TradingMixer systems, data, personnel, and contractors. TradingMixer is operated by a small team. The Founder & Managing Member is the designated Security Officer, accountable for this policy, and reviews it at least once a year and after any significant change or security incident.

1. Scope and Architecture

TradingMixer runs entirely on managed (platform-as-a-service) cloud services in Microsoft Azure data centers in the United States. These are Azure App Service, Azure Functions, Azure Static Web Apps, Azure Cosmos DB, Azure Storage, Azure Key Vault, Azure Monitor (Application Insights and Log Analytics), and Azure Communication Services. We do not operate our own servers, virtual machines, or data centers. Infrastructure is defined as code (Azure Bicep) and deployed through automated pipelines.

2. Data Classification and Handling

Class	Examples	Handling requirements
Restricted	Brokerage OAuth access tokens and legacy API keys, application secrets (OAuth client secret, payment-processor keys, identity-provider secrets)	Stored only in encrypted services (Azure Key Vault for application secrets; the encrypted database for user tokens). Never shown in the user interface, written to logs, sent by email, or stored in source code. Accessible only to the running application through managed identities.
Confidential	User email address, sign-in identifier, webhook configuration, order and transaction history, subscription status	Encrypted in transit and at rest. Each record is scoped to the owning user, and each user can see only their own data. Used only to provide the service. Never sold.
Internal	Operational logs, telemetry, infrastructure configuration	Access restricted to authorized personnel. Logs are retained for up to 90 days.
Public	Website content, published policies	Changes are reviewed before publication.

We collect only the data needed to run the service. We never collect brokerage passwords. Users sign in to their brokerage on the brokerage's own page, and we receive only the OAuth token issued after the user selects Allow. Payment card data is handled entirely by our payment processor (Stripe) and never reaches TradingMixer systems. Retention: order and transaction records are deleted automatically after three years, billing event records after 30 days, and account records when the user deletes their account.

3. Access Control and Privileged Access Management

• End users sign in through Microsoft Entra External ID. Every app page and API that handles user data requires an authenticated session, and every data query is scoped to the signed-in user.
• Least privilege for services: application components authenticate to the database, storage, Key Vault, and email services with Azure managed identities and role-based access control (RBAC). Shared-key access to Azure Storage is disabled. Key Vault uses the RBAC permission model.
• Privileged access to production (Azure subscription, source-code repository, payment-processor dashboard, DNS, and identity tenant) is limited to the Security Officer. Multi-factor authentication is required on every administrative account. No shared administrator accounts are used.
• Deployments run through GitHub Actions using OpenID Connect federated credentials rather than long-lived deployment passwords.
• Brokerage authorization is requested with the narrowest scope the integration needs to read account information and place orders at the user's direction. TradingMixer cannot withdraw or transfer funds. Users can revoke access at any time from their brokerage or by deleting the connection in the app.
• Access reviews: privileged accounts and role assignments are reviewed quarterly and when personnel or contractors change. Access is removed immediately when it is no longer needed.

4. Encryption of Data at Rest and in Transit

• In transit: all public endpoints are HTTPS-only with TLS 1.2 or higher. The website sends HTTP Strict Transport Security (HSTS). Connections from the app to Azure services and to brokerage APIs use TLS.
• At rest: Azure Cosmos DB and Azure Storage encrypt all data at rest with AES-256 using Microsoft-managed keys. Application secrets are stored in Azure Key Vault and injected into the application at runtime through Key Vault references.
• OAuth protection: the OAuth "state" value is signed (HMAC) and bound to the signed-in user, compared in constant time, and expires after 10 minutes, to prevent cross-site request forgery and replay.

5. Vulnerability Management and Patch Management

• Because we use managed platform services, Microsoft patches the operating systems, web servers, and language runtimes. Applications target a supported long-term-support .NET release.
• Automated dependency monitoring (GitHub Dependabot) checks application libraries and build actions weekly and raises update pull requests. Every change passes automated build and test pipelines before deployment.
• Remediation targets from disclosure or detection: critical within 7 days, high within 30 days, medium and low in the next scheduled maintenance cycle.
• Workstations used to administer TradingMixer receive operating-system and security updates automatically.
• Security issues can be reported to hello@tradingmixer.com. We acknowledge reports within 3 business days.

6. Endpoint Protection (Malicious Code)

• Production: there are no customer-managed servers. Workloads run on hardened, Microsoft-managed PaaS hosts, and we do not install software on the underlying hosts. Only code built by our CI/CD pipeline from the reviewed source repository is deployed.
• Corporate workstations: devices used to administer TradingMixer run a supported version of Windows with Microsoft Defender Antivirus (real-time protection and tamper protection enabled, signatures updated automatically), Windows Defender Firewall enabled on all network profiles, automatic security updates, full-disk encryption, and an automatic screen lock.

7. Logging and Monitoring

Application and platform telemetry is collected in Azure Application Insights and Log Analytics and retained for up to 90 days. We monitor for errors, failed orders, and unusual activity. The app emails users immediately when an order they configured is rejected, so problems are not silent. Credentials and tokens are excluded from logs.

8. Incident Response and Disaster Recovery

8.1 Incident Response

1. Detect and triage: alerts, monitoring, user reports, and vendor notices are triaged by the Security Officer, who classifies severity.
2. Contain: actions may include disabling affected webhooks (the app's kill-switch), revoking brokerage tokens, rotating secrets in Key Vault, and blocking affected accounts.
3. Eradicate and recover: fix the root cause, redeploy from source-controlled infrastructure code, and restore data if needed.
4. Notify: affected users, and any brokerage or partner whose customers or systems are affected, are notified without undue delay, within 72 hours of confirming an incident involving their data or within any shorter period required by law or contract.
5. Learn: a written post-incident review records the cause, impact, and corrective actions.

8.2 Disaster Recovery and Business Continuity

• Azure Cosmos DB uses continuous backup with point-in-time restore for the previous 30 days.
• Production Azure Storage is geo-redundant (GRS).
• All infrastructure can be recreated from code (Bicep) and the CI/CD pipelines. Application secrets are held in Key Vault, which has soft-delete protection.
• Recovery objectives: restore service within 24 hours (RTO), with data loss limited to minutes (RPO) through point-in-time restore.
• The service fails safe. If the brokerage or our systems are unavailable, it does not retry or substitute orders silently. It halts and notifies the user.

9. Physical Security

TradingMixer has no data centers or server rooms of its own. Physical security of production systems is provided by Microsoft Azure data centers, which are independently audited (for example, SOC 1/SOC 2 and ISO/IEC 27001). Administrative workstations are kept in a private, access-controlled location, are encrypted, lock automatically, and are never left unattended while unlocked. Paper records containing customer data are not kept.

10. Vendor Risk Management

We use only established providers with independent security attestations. We review each provider's security and compliance documentation before onboarding and at least annually. Each provider receives only the data it needs.

Provider	Purpose	Data shared
Microsoft Azure	Hosting, database, storage, secrets, monitoring, email delivery	All service data (encrypted)
Microsoft Entra External ID	User sign-in	Email address, sign-in identifiers
Stripe	Subscription billing and payments	Email address, subscription details (card data is entered directly with Stripe)
Linked brokerage (via OAuth)	Executing the user's orders in the user's own account	Orders the user configured; account information needed to place them
GitHub	Source code and CI/CD	Source code only (no customer data)

We remove vendor access and request data deletion when a relationship ends.

11. Secure Development

• Changes are made through pull requests and must pass automated builds and tests before deployment to production.
• Secrets are kept out of source code and supplied through Key Vault or the deployment platform's secret store.
• User input, including webhook payloads, is validated before use, and each webhook has a unique, unguessable identifier.

12. Training and Enforcement

Anyone given access to TradingMixer systems must read and follow this policy before receiving access. Violations may result in immediate removal of access.

13. Contact

UnderForest LLC (TradingMixer) · Security Officer: Founder & Managing Member
Email: hello@tradingmixer.com
Website: https://www.tradingmixer.com