Cybersecurity Policy

1. Purpose

This policy defines the technical controls that protect JorgAI's systems and the customer data they hold against unauthorized access, misuse, disruption and loss. It is the companion to the Information Security Policy, which sets governance, data handling and personnel rules; this document covers how the platform is built, run, monitored and recovered.

2. Scope

All production systems operated by JorgAI LLC: the web application and API, background workers, the realtime market scanner, databases and caches, the marketing website, the mobile applications, the continuous integration pipeline, cloud accounts and source repositories, and the vendor services that support them.

3. System overview

All production infrastructure is in the United States (AWS us-east-1).

4. Network and infrastructure security

Application services run in private subnets; the only public entry point is the load balancer, which terminates TLS. The database and cache have no public endpoint and accept connections only from the application security group. There is no SSH exposure; operational tasks run as short-lived containers inside the private network using the same images as production. Development and test environments are separate from production and contain no customer data. Infrastructure changes are made through the AWS console or CLI under named identities and are recorded in CloudTrail.

5. Identity and access management

6. Secrets and encryption

All application secrets, vendor credentials and the data encryption key live in AWS Secrets Manager and are injected into containers at start. None are stored in source code, container images or on developer machines, and repositories are checked for secret patterns. Customer brokerage tokens and other restricted fields are encrypted with authenticated symmetric encryption before they are written to the database, with the key held separately in Secrets Manager. Storage, backups and snapshots are encrypted at rest. All traffic, internal and external, uses TLS. Secrets are rotated on suspected exposure, on personnel or vendor change, and on a schedule; rotation is logged and new values are deployed through the pipeline.

7. Application security

The application enforces per-customer data scoping on every query, so one customer's records are never returned to another. Input is validated at the API boundary. Browser sessions are protected with a content security policy, standard security headers and short-lived access tokens with revocable refresh tokens. Broker connections use each broker's OAuth flow with revocable tokens, or API keys the customer creates; JorgAI never stores brokerage passwords and never uses unofficial APIs. Automated trading acts only within limits the customer sets, including position size, daily trade caps, stop-losses and an optional approval step for every buy, and the software has no ability to withdraw funds. Automated tests covering authentication, authorization, broker handling and the trading rules run on every change before deployment.

8. Vulnerability and patch management

Dependencies and base images are monitored for published vulnerabilities and updated promptly, with critical and high severity items prioritized and deployed through the normal pipeline. An internal security review covering the application, website, cloud configuration and dependencies was completed in October 2026; critical findings were remediated within one day and the remaining items are tracked to closure with owners and dates. JorgAI intends to commission an independent penetration test and will remediate high and critical findings before closure and share the results with partners under review.

9. Logging, monitoring and alerting

Logs exclude tokens, passwords and encryption keys. Security-relevant events, failed sign-in patterns and error spikes alert the founder.

10. Change management and secure deployment

1. Changes are made on a development branch in version control.
2. The continuous integration pipeline runs the automated test suite and the frontend build; a failing suite blocks the deploy.
3. Merges to the protected main branch trigger the pipeline, which builds versioned container images and deploys to production using short-lived credentials.
4. Database migrations are applied before the code that depends on them.
5. Rollback is a redeploy of the previous release.
6. No manual change is made to production outside this process except during an incident, in which case it is logged in the incident record and reconciled afterward.

11. Backup and recovery

Backups are encrypted and held in the same region under the same access controls as production.

12. Incident response

JorgAI follows its Incident Response Procedure. In summary: contain within hours (revoke affected broker tokens, delete them from JorgAI systems, rotate the encryption key and any exposed credentials, invalidate affected sessions, pause automated trading for affected accounts); assess scope from the audit log, CloudWatch, Sentry and CloudTrail; notify affected partners in writing within 24 hours of confirming unauthorized access to their customers' information and provide updates until closure; notify affected customers without unreasonable delay and within applicable law, with a 72-hour target; restore service within the recovery objectives above; and deliver a written post-incident report with root cause and corrective actions within 10 business days.

13. Third-party and broker connections

Vendors are limited to those the service requires, are listed in the Information Security Policy, and are reviewed before use and annually. Broker connections use only each broker's sanctioned API and authorization flow, with scoped, revocable tokens. Partner notification commitments for outages and breaking changes are kept in the relevant partner agreements: outage notice within four hours of detection, five business days for maintenance that could interrupt order placement, and thirty days for breaking changes.

14. Endpoint and administrative device security

Devices used to administer JorgAI systems use full-disk encryption, automatic screen lock, current operating system updates and endpoint protection. Production data is never stored on them. Administrative sessions use multi-factor authentication and are closed when not in use.

15. Review and approval

This policy is reviewed at least annually and after any significant incident or architectural change. Approved by the founder of JorgAI LLC, October 2026.

Appendix A: Control mapping