ainventry
Book a demo

Draft — pending legal review

Security

How we protect your data and operations.

ainventry takes a layered approach to security. This page describes the technical and organisational measures we have in place to protect your data. It is intended to support your security evaluation and Intuit's security questionnaire requirements.

Encryption in Transit

All communication between your browser or API client and ainventry servers is encrypted using TLS 1.2 or higher. We do not accept connections over unencrypted HTTP for any authenticated endpoint. HSTS (HTTP Strict Transport Security) is enforced on the ainventry.com domain.

API-to-API communication between ainventry services also uses encrypted channels.

Encryption at Rest

Sensitive data is encrypted at rest:

  • Database encryption: the database (PostgreSQL) is hosted on Railway's infrastructure, which provides at-rest encryption for database storage volumes.
  • QuickBooks Online OAuth tokens: access tokens and refresh tokens issued by Intuit are encrypted using AES (Fernet symmetric encryption) before being stored in the database. Encryption uses a dedicated key (QBO_CREDENTIAL_KEYS) that is held separately from general application configuration, never stored in source code or version control, and injected at runtime via the Railway environment configuration.
  • Other sensitive secrets (API keys, broker credentials): managed as environment variables through Railway, not stored in code.

Authentication and Session Security

  • Users authenticate via email and password; passwords are stored as salted bcrypt hashes.
  • Authentication tokens are short-lived JWT (JSON Web Tokens) transmitted via Secure and HttpOnly cookies, preventing access by client-side JavaScript.
  • Sensitive pages and all API endpoints are not cached by browsers or CDN layers.
  • Multi-factor authentication (MFA/2FA) is not currently offered; this is on our roadmap.

Multi-Tenant Data Isolation

ainventry is a multi-tenant platform. Every data record — items, stock movements, orders, customers, suppliers, and all integration data — is scoped to your organisation (org_id present on every business record). This isolation is enforced at the database query level:

  • All API endpoints apply an automatic organisation-scope filter to every query
  • Cross-organisation access returns HTTP 404 (not 403 — we do not confirm the existence of resources belonging to other organisations)
  • Integration data (QuickBooks OAuth tokens, realmId) is isolated per organisation connection

Credential and Data Logging Policy

We explicitly do not log:

  • QuickBooks OAuth tokens (access or refresh)
  • QuickBooks company identifiers (realmId) in log output
  • User passwords at any stage
  • Other credential material

Role-Based Access Control (RBAC)

  • Owner / Admin: full read/write access; can manage users and integrations
  • Standard user: access to operational features as configured by the admin
  • API tokens: scoped at creation to specific operations; tokens can be revoked at any time

Vulnerability Management

  • Dependency scanning: Python and JavaScript packages are scanned for known CVEs in CI/CD.
  • Security patching: critical CVEs are addressed within 7 days (CVSS 9.0+), 30 days (CVSS 7.0–8.9).
  • Code review: all changes go through peer review before merging.
  • Penetration testing: no independent penetration test has been completed to date. We intend to commission one before increasing scale.

Infrastructure and Hosting

  • Backend: hosted on Railway (US-based). Railway provides network isolation, managed database backups, and platform-level encrypted storage.
  • Frontend / CDN: served from Cloudflare Pages with global CDN. Cloudflare provides DDoS mitigation, WAF, and TLS termination.
  • Database: PostgreSQL 17 managed by Railway. Automatic daily backups are retained per Railway's platform defaults (typically 7 days on paid plans).

Backup and Disaster Recovery

  • Database backups: automated daily backups via Railway. Backup retention follows Railway platform defaults. A formal restore drill has not yet been conducted; this is scheduled before wider production rollout.
  • Recovery objectives: Recovery Point Objective (RPO) of approximately 24 hours based on daily backup cadence. Recovery Time Objective (RTO) has not yet been formally tested; target is within 4 hours for the database and under 5 minutes for the frontend (re-deploy from source control). These figures are indicative until a restore drill confirms them.
  • Frontend: statically hosted on Cloudflare Pages; recovery is a re-deploy from source control (typically <5 minutes).

Compliance Posture

GDPR

ainventry is operated in compliance with the EU General Data Protection Regulation (GDPR). Our data protection practices are described in the Privacy Policy. We maintain a Record of Processing Activities (RoPA) internally and have Data Processing Agreements in place with all subprocessors.

SOC 2

ainventry has not yet completed a SOC 2 Type II certification. We are building toward SOC 2 Type II readiness: our security controls, access management, change management, and incident response procedures are designed to be consistent with SOC 2 Trust Services Criteria.

Intuit Developer Program

ainventry participates in the Intuit Developer Program. Our handling of QuickBooks Online data is governed by the Intuit Developer Agreement, which requires that QuickBooks data be used solely to provide the service the user has authorised and not shared with or sold to third parties.

Intuit and QuickBooks are registered trademarks of Intuit Inc. Used with permission.

Incident Response

  1. Detection: security events are monitored through application error tracking and infrastructure alerts.
  2. Triage and containment: on detection of a suspected breach, the affected system or account is isolated as rapidly as possible, targeting within 1 business day for initial response.
  3. Notification: in the event of a confirmed personal data breach, we notify the relevant supervisory authority within 72 hours as required by GDPR.
  4. Post-incident review: all confirmed incidents result in a written post-incident review and remediation plan.

Responsible Disclosure

If you discover a security vulnerability in ainventry, please report it responsibly to andreidiachenko95@gmail.com. We commit to acknowledging your report within 1 business day and not pursuing legal action against good-faith security researchers.

Contact

For security questions: andreidiachenko95@gmail.com
For data-privacy questions: andreidiachenko95@gmail.com
For general inquiries: andreidiachenko95@gmail.com