ARKONOMY

AI FINANCIAL AUTOPILOT

Cybersecurity Policy

Arkonomy ("we", "our", or "us") is committed to protecting the confidentiality, integrity, and availability of user data and platform systems. This policy describes the controls we maintain to secure your information and our infrastructure.

1. Purpose and Scope

This policy applies to all Arkonomy systems, services, and infrastructure — including the web and mobile applications, backend services, third-party integrations, and any personnel or contractors with access to production systems.

The objective is to establish a consistent baseline of security controls that protects user financial data, prevents unauthorised access, and ensures continued platform availability.

2. Data Classification

All data handled by Arkonomy is classified into three tiers that govern how it is stored, accessed, and transmitted:

• Public — information intentionally available without restriction (e.g. marketing content, these policy pages). No access controls required beyond standard hosting.
• Internal — anonymised aggregates, usage metrics, and error logs used for operational purposes. Access restricted to authorised personnel. Not linked to individual identities.
• Sensitive PII — email addresses, bank transaction data, savings goals, investment activity, and payment information. Subject to the strictest controls: encryption at rest and in transit, row-level security, MFA-gated access, and access logging.

3. Access Control

Access to Arkonomy systems follows the principle of least privilege:

• Multi-factor authentication (MFA) is required on all production platforms, including Supabase, Vercel, GitHub, and Stripe.
• Row-level security (RLS) is enforced at the database layer via Supabase — each user can only access their own records, regardless of application-layer behaviour.
• Encrypted environment variables — all API keys, secrets, and service credentials are stored as encrypted environment variables. They are never embedded in source code, client bundles, or version control.
• Server-side execution — all calls to third-party APIs (Plaid, Stripe, Anthropic) are made exclusively from authenticated server-side edge functions, never from the client.
• Access rights are reviewed regularly and revoked promptly when no longer required.

4. Encryption

All user data is protected by encryption at every layer:

• In transit — all communication between clients and servers uses TLS 1.2 or higher. Plain HTTP connections are rejected.
• At rest — all data stored in Supabase (hosted on AWS) is encrypted at rest using AES-256. Database backups are encrypted to the same standard.
• Session tokens — short-lived JWTs are used for authentication. Refresh tokens are rotated on each use and invalidated on logout.

5. Vulnerability Management

We maintain an active programme to identify and remediate security vulnerabilities:

• Dependency auditing — npm audit is run regularly and as part of the deployment process. Known CVEs are addressed promptly.
• Dependabot — automated dependency update alerts are enabled on the GitHub repository to surface newly disclosed vulnerabilities.
• Security reviews — code changes touching authentication, data access, or third-party integrations are reviewed for security implications before deployment.
• Patch SLAs — critical/high severity vulnerabilities are remediated within 72 hours of confirmation; moderate issues within 30 days.

To report a vulnerability, please contact us at hello@arkonomy.com. We ask that you allow us reasonable time to investigate before any public disclosure.

6. Incident Response and Disaster Recovery

In the event of a security incident, we follow a structured five-step response process:

• Contain — isolate affected systems to prevent further exposure.
• Assess — determine the scope, nature, and root cause of the incident.
• Notify — inform affected users and relevant authorities as required by applicable law, without undue delay.
• Remediate — apply fixes to resolve the underlying vulnerability.
• Document — record a full post-incident report and implement controls to prevent recurrence.

Disaster recovery targets are maintained in line with our infrastructure providers' SLAs:

• Recovery Time Objective (RTO) — 4 hours for critical service restoration.
• Recovery Point Objective (RPO) — 24 hours maximum data loss in a worst-case scenario, based on automated daily backups.

7. Physical Security

Arkonomy does not operate physical data centres. All compute, storage, and networking infrastructure is hosted on cloud platforms that maintain their own certified physical security controls:

• Vercel — SOC 2 Type II compliant edge compute and hosting platform.
• AWS (via Supabase) — ISO 27001 and SOC 2 Type II certified facilities with controlled physical access, biometric authentication, and 24/7 environmental monitoring.

8. Vendor Risk Management

All third-party vendors who access or process user data are evaluated for security posture and monitored on an ongoing basis:

9. Policy Review

This policy is reviewed at least annually, or following any significant security incident, major infrastructure change, or relevant regulatory development. Updated versions will be published at this URL with a revised effective date.

10. Contact

For security questions, vulnerability reports, or data security concerns, contact us at hello@arkonomy.com.

Please disclose vulnerabilities responsibly — contact us privately and allow reasonable time for investigation before any public disclosure.

---