Information Security Policy

1. Purpose

This policy establishes how JorgAI LLC ("JorgAI") protects the confidentiality, integrity and availability of the information it handles while operating the JorgAI platform. The platform runs rules-based automated trading inside customers' own brokerage accounts, so the data it holds includes brokerage access tokens and account activity that customers and their brokers trust JorgAI to protect. The policy exists to make the rules for that protection explicit, to assign responsibility for them, and to give partners a clear account of how customer data is handled.

2. Scope

The policy applies to all information assets owned or operated by JorgAI: the web application and API (portal.jorgai.com), the marketing website (jorgai.com), the iOS and Android applications, background workers, databases, caches, cloud accounts, source code repositories, vendor services, and the devices used to administer them. It applies to every person with access to those assets, today the founder and in future any employee or contractor, and to every vendor that processes JorgAI data. It covers all data classified in section 5, including data received from customers' connected brokerage accounts.

3. Policy statements

JorgAI commits to the following principles. The remaining sections state the controls that implement them.

1. Customer data is used only to deliver the service the customer asked for. It is not sold, licensed, shared for advertising, or used to train machine learning models.
2. Access to systems and data is granted on least privilege, to named individuals, with multi-factor authentication, and is removed the day it is no longer needed.
3. Restricted data is encrypted in transit and at rest, with keys managed separately from the data they protect.
4. Brokerage access is obtained only through the broker's sanctioned authorization flow; JorgAI never asks for, stores or uses a brokerage password.
5. Every change to production is tested, reviewed, deployed through an automated pipeline, and reversible.
6. Security-relevant activity is logged, retained and reviewed.
7. Security incidents are contained, assessed, reported to affected partners and customers, and followed by a written root-cause report.
8. Vendors are limited to what the service requires and are reviewed before use and annually thereafter.

4. Roles and responsibilities

JorgAI is operated by its founder. No other person holds system access as of the effective date. Should personnel be added, the onboarding and offboarding steps in section 6.4 apply before any access is granted.

5. Data classification and handling

Handling rules for restricted and confidential data: no copies to unmanaged storage, personal email or messaging; no screenshots containing customer data in tickets or chat; test environments use synthetic data only; exports for support are made from the application by the founder and deleted after use.

6. Access control and authentication

6.1 Principles

Access is granted on least privilege to named identities. Shared accounts are not used. Every access path to production requires multi-factor authentication. Access rights are reviewed quarterly and whenever a person, vendor or system changes.

6.2 Infrastructure access

Cloud access uses named AWS IAM identities with policies limited to the task; the operational identity used for routine tasks cannot modify identity and access management. Source code is held in private repositories with multi-factor authentication required for every account. The production database accepts connections only from inside the private network; there is no public database endpoint and no exposed SSH.

6.3 Application access

Customer accounts require email verification; passwords are hashed with bcrypt; sign-in is rate-limited; customers may enable multi-factor authentication; sessions can be revoked server-side. Administrative functions require a separate admin role and step-up authentication for sensitive actions.

6.4 Joiners, movers and leavers

Before access is granted, a new person accepts this policy and receives only the access their role requires, through their own named identity. When a role changes, access is adjusted the same day. When an engagement ends, all access is revoked the same day and any credentials the person could have seen are rotated.

7. Cryptography and key management

Data in transit is protected with TLS on every connection, including connections to brokers and vendors. Restricted fields, including customer brokerage tokens, are encrypted at rest with authenticated symmetric encryption before they are written to the database. The data encryption key is held in AWS Secrets Manager, separate from the database, and is injected into the application at start; it is never stored in source code, container images or on personal devices. Databases, backups and snapshots are encrypted at rest. Keys and credentials are rotated on suspected exposure, on personnel or vendor change, and on a schedule, and rotation is logged.

8. Brokerage credentials and customer account data

Brokerage access is obtained only through the broker's own OAuth authorization flow or through API keys the customer creates at the broker. JorgAI never asks for, stores or uses a brokerage password, and never uses unofficial APIs or screen automation. Tokens are used only to read the connected account and to place orders within the limits the customer has set; JorgAI cannot withdraw or transfer funds. Disconnecting a broker deletes the stored tokens immediately and stops all activity for that account. Brokerage account data is not sent to AI model providers; models receive market data and the customer's own rule settings only. Customer data is retained while the account is active and for the customer's own trade history, and is deleted when the customer deletes their JorgAI account.

9. Vendor and subprocessor management

Vendors that process confidential data are listed in Appendix A, are limited to the purpose stated there, and operate under written terms. Before a vendor is added, JorgAI reviews its security documentation and the data it would receive, and confirms the data is limited to what the purpose requires. Vendors are reviewed annually. When a vendor is retired, its access is removed and JorgAI confirms deletion of any data it held. The current subprocessor list is also published in the Privacy Policy at jorgai.com/privacy.

10. Secure development and change management

All changes are made in version control on a development branch and merged to a protected main branch. Every production deploy runs the automated test suite in continuous integration before building, deploys only through the pipeline using short-lived credentials, applies database migrations before the code that depends on them, and can be rolled back by redeploying the previous release. Dependencies are updated when security advisories apply. Secrets are never committed to source control, and the repositories are checked for secret patterns.

11. Logging, monitoring and audit

The application maintains an audit log of sign-ins, broker connections and disconnections, settings changes and administrative actions, attributed to the acting identity. Infrastructure and container logs are retained in CloudWatch, application errors in Sentry, and cloud API activity in CloudTrail. Logs never contain tokens, passwords or encryption keys. Security-relevant events generate alerts to the founder, and logs are reviewed during incident handling and the quarterly access review.

12. Business continuity

The production database has automated daily backups and point-in-time recovery; application releases are versioned container images that can be redeployed. Recovery objectives (restore within 4 hours, data loss limited to 5 minutes) and the recovery procedure are defined in the Cybersecurity Policy. Restores are tested when the backup configuration changes and at least annually.

13. Incident response

Suspected security incidents are handled under the JorgAI Incident Response Procedure: contain within hours (revoke affected broker tokens, rotate keys, invalidate sessions, pause automated trading for affected accounts); assess scope from logs; notify affected partners in writing within 24 hours of confirming unauthorized access to their customers' information; notify affected customers without unreasonable delay and within the timelines of applicable law, with a 72-hour target; and deliver a written post-incident report within 10 business days. Anyone with access to JorgAI systems must report a suspected incident to the founder immediately.

14. Acceptable use and endpoint security

Personnel access JorgAI systems only from devices with full-disk encryption, automatic screen lock, current operating system updates and endpoint protection enabled. Production data is never copied to personal devices, removable media or unmanaged cloud storage. Credentials are kept in a password manager and never shared or reused. Administrative sessions are closed when not in use.

15. Compliance, exceptions and enforcement

JorgAI does not currently hold a SOC 2 or ISO 27001 attestation and says so to partners that ask; an independent penetration test is planned. Internal control reviews are performed at least annually; the most recent, in October 2026, covered the application, website, cloud configuration and dependencies, and its findings are tracked to closure. Exceptions to this policy require written approval from the founder, a compensating control, and an expiry date. Violations by personnel or contractors result in removal of access and may end the engagement.

16. Review and approval

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

Appendix A: Subprocessors and third-party services

Appendix B: Control summary