CYBERSECURITY POLICY

Aizeum, Inc. (“we”, “us”, “our”) operates the Aizeum voice AI assistant, a cloud-native SaaS and mobile application that connects to brokerage accounts, cryptocurrency exchanges, and productivity platforms on behalf of users. This policy documents our information security program, technical controls, and governance commitments as they apply to the data we process, the infrastructure we operate, and the third-party integrations we maintain.

Our production infrastructure is hosted on Railway (backend API, PostgreSQL, Redis) and Vercel (web application). Both platforms operate on AWS infrastructure and hold SOC 2 Type II certifications. Our mobile applications are distributed on iOS and Android.

Security questions and vulnerability disclosures should be directed to michael@aizeum.com.

Aizeum classifies all data assets into four sensitivity tiers. Classification is assigned at the time data is created or received. The Head of Engineering serves as Data Owner and is responsible for maintaining classification decisions and data handling standards.

Handling requirements for Restricted data:

• —Access is limited to authenticated system processes and named engineers with documented business justification. All access is logged.
• —OAuth tokens and brokerage integration credentials are encrypted at rest and never exposed to frontend clients or included in application logs.
• —Financial data obtained from brokerage integrations (positions, order history, account details) is used only to fulfill the user's explicit request and is not retained beyond the active session unless the user has enabled a portfolio tracking feature.
• —Tokens are revoked and deleted within 24 hours of a user disconnecting an integration or deleting their account.
• —Data minimization: OAuth scopes requested from third-party platforms are limited to the minimum required for the features the user has authorized.

Access to Aizeum systems and data is governed by the principle of least privilege. Each employee, contractor, and automated service account is granted only the minimum permissions necessary to perform their specific function.

Authentication and MFA

• —Multi-factor authentication (MFA) is mandatory for all access to production infrastructure, including cloud platform consoles (Railway, Vercel), code repositories (GitHub), and database administration interfaces. MFA enforcement is technical where the platform supports it.
• —User authentication is implemented via HS256 JSON Web Tokens (30-day expiry) with optional MFA enrollment (TOTP authenticator app, email OTP, or hardware passkeys via WebAuthn).
• —Trading and order-placement operations are gated behind a dedicated MFA requirement (require_mfa_for_trading) that validates an active MFA claim in the session token, independent of login MFA.
• —Mobile sessions are stored in hardware-backed secure storage (expo-secure-store) with optional biometric (Face ID / fingerprint) re-authentication after 1 hour of background inactivity.

Access Provisioning and Reviews

• —Production system access is provisioned through a documented request and approval process. The Head of Engineering approves all production access grants.
• —Quarterly access reviews are conducted for all production systems. Access for terminated employees and contractors is revoked within one business day of separation.
• —Shared credentials are prohibited. Service accounts are issued with scoped, purpose-specific permissions and credentials are rotated at least every 90 days.
• —Standing root or global administrator access is not permitted. Privileged elevation is performed on a just-in-time basis with all privileged sessions logged.

Credential and Secret Management

• —All internal API keys, service credentials, and third-party OAuth application secrets are stored exclusively as environment variables in Railway and Vercel's secrets management systems. No credentials are committed to source control.
• —OAuth credentials obtained from third-party integrations (brokerage accounts, productivity platforms) are stored in our production database. Application-layer field encryption for these values is an active roadmap item.
• —The JWT signing secret is a strong random value stored as an environment variable; fallback development values are blocked in production by environment checks.

Data in Transit

• —All data transmitted between clients and Aizeum services is encrypted using TLS 1.2 or higher (TLS 1.3 preferred). Plaintext HTTP is not permitted in production. Railway and Vercel enforce TLS termination on all public endpoints.
• —iOS app transport security (ATS) is enforced (NSAllowsArbitraryLoads: false), requiring HTTPS for all network connections from the iOS application.
• —All API communications with third-party brokerage and productivity platforms use the encryption standards specified by those platforms and are not downgraded.
• —HMAC-SHA256 is used for webhook signature verification (Stripe) and for URL signing (MoonPay). SHA-256 is used for hashing PII before transmission to analytics endpoints (Meta Conversions API).
• —WebSocket connections for real-time voice streaming use the Secure WebSocket protocol (WSS).

Data at Rest

• —Production PostgreSQL and Redis instances are hosted on Railway's managed infrastructure, which provides provider-level AES-256 encryption at rest for all stored data.
• —Mobile session tokens are stored in expo-secure-store, which uses hardware-backed encryption (Keychain on iOS, Android Keystore on Android).
• —APNs push notification certificates and private keys are stored as base64-encoded environment variables and never written to disk in the production environment.

Endpoints and Key Management

• —All company-issued and personal devices used to access production systems are required to have full-disk encryption enabled (FileVault for macOS, BitLocker for Windows).
• —Encryption keys for production data stores are managed by the cloud provider's key management service. No encryption keys are stored in application code, configuration files, or source control.
• —Sensitive values including tokens, credentials, and PII are masked or excluded from application logs at the code level.

Aizeum employs automated and periodic manual processes to identify and remediate security weaknesses across application code, infrastructure, and third-party dependencies.

Scanning and Detection

• —Automated dependency vulnerability scanning (GitHub Dependabot / security alerts) runs on every code merge across the Python backend, Next.js web app, and React Native mobile app.
• —Critical and high-severity CVEs identified in production dependencies are treated as blocking issues and remediated before the next production deployment.
• —Pre-production code review is required for all changes touching authentication, authorization, session management, or financial data processing paths.
• —Aizeum maintains a responsible disclosure program. Researchers who identify vulnerabilities may report them to michael@aizeum.com. We commit to acknowledging reports within 2 business days and providing remediation timelines within 5 business days.

Remediation SLAs

Patch Management

• —Security patches for production runtimes (Python, Node.js) and operating system images are applied within 30 days of release. Critical security patches are applied within 72 hours. Security patching takes priority over feature development.
• —Aizeum conducts a third-party penetration test annually, performed by a qualified external security firm. Findings are tracked to remediation. An executive summary of the most recent test is available to authorized integration partners upon written request to michael@aizeum.com.

Incident Classification

Response Roles

• —Head of Engineering serves as Incident Commander for all P1 and P2 incidents. The CEO is notified immediately upon declaration of a P1 incident.
• —Legal counsel is engaged for any incident involving confirmed or probable unauthorized disclosure of user data.
• —On-call rotation ensures 24/7 paging capability for P1 incidents.

Partner and User Notification Commitments

Disaster Recovery

• —Production databases are backed up daily with point-in-time recovery enabled via Railway's managed PostgreSQL service. Backups are retained for a minimum of 7 days and stored in a geographically separate region.
• —Recovery Time Objective (RTO): 4 hours for core brokerage and financial integration features; 8 hours for full service restoration.
• —Recovery Point Objective (RPO): 1 hour for production data.

Testing and Review

• —The incident response plan is tested annually via a tabletop exercise with documented outcomes and identified improvements.
• —Disaster recovery procedures are tested at least annually with recovery time results documented.
• —The incident response plan is reviewed and updated following every P1 or P2 incident.
• —Application logs are retained for a minimum of 12 months. Incident artifacts and response records are retained for a minimum of 3 years.

Aizeum is a cloud-native, remote-first company. We do not own or operate physical data centers. All production infrastructure is hosted on Railway and Vercel, both of which operate on Amazon Web Services infrastructure. AWS maintains SOC 2 Type II, ISO 27001, and PCI DSS certifications covering physical and environmental security at its data center facilities. Railway and Vercel publish their own SOC 2 compliance documentation and security pages.

Endpoint and Device Security

• —All devices — company-issued or personal — used to access Aizeum production systems, source code, or Restricted data must have full-disk encryption enabled (FileVault for macOS; BitLocker for Windows). This requirement is verified during onboarding and as part of periodic access reviews.
• —Automatic screen lock is required to activate after no more than 5 minutes of inactivity on any device with access to production systems.
• —Company-issued devices are enrolled in a mobile device management (MDM) system that enforces encryption, screen lock, and remote wipe capability.
• —Any lost or stolen device must be reported to the Head of Engineering immediately. Remote wipe is initiated within 1 hour of confirmed loss.

Remote Work

• —Employees and contractors working remotely must ensure that screens displaying Restricted or Confidential data are not visible to unauthorized individuals in shared spaces. A physical privacy screen is recommended for work in public locations.
• —Production credentials and API keys must not be entered on shared, public, or unmanaged devices.

Physical Media

• —Printed documents containing Restricted or Confidential data must be shredded before disposal.
• —Hardware storage media being decommissioned is securely wiped per NIST SP 800-88 guidelines prior to disposal or reuse.

Aizeum evaluates the security posture of third-party vendors and service providers before onboarding and on an ongoing basis. Vendors are tiered based on the sensitivity of data they access or the criticality of the services they provide.

Vendor Tiers

Onboarding Due Diligence

• —Before onboarding any Tier 1 or Tier 2 vendor, Aizeum reviews the vendor's current SOC 2 Type II report or equivalent security certification and their incident notification commitments.
• —All Tier 1 vendors that process personal data must execute a Data Processing Agreement (DPA) prior to access. DPAs include: purpose limitation, breach notification within 72 hours, sub-processor disclosure requirements, and data deletion obligations upon contract termination.
• —Security questionnaire responses are required for Tier 1 vendor onboarding where a SOC 2 report is not available.

AI and LLM Sub-Processors

Ongoing Monitoring and Offboarding

• —Tier 1 vendors are reassessed annually. Aizeum monitors vendor security advisories and responds to vendor-reported incidents within 24 hours.
• —Upon termination of a vendor relationship, Aizeum requests written confirmation of data deletion, revokes all API credentials, and retains documentation of the offboarding for a minimum of 3 years.
• —Sub-processors that handle user personal data are disclosed in the Aizeum Privacy Policy.