Security Practices

At Opagio, we take the security of your data seriously. This page describes the technical and organizational measures we have in place to protect the information you entrust to us.

1. Infrastructure Security

Data Sovereignty and EU Residency. All customer data at rest is stored within the European Economic Area and United Kingdom. Our primary infrastructure runs on Google Cloud Platform's eur3 multi-region (London, Belgium, Netherlands), with database-level delete protection enabled. Only authentication (Firebase Auth), payment processing (Stripe), and transactional email (Resend) sub-processors process limited data in the United States — these do not include your financial or analytical data.

Your general ledger data, classification outputs, valuation models, and analytical results are stored within Opagio's European infrastructure. Where features require LLM-class language processing, limited task-specific extracts are transmitted to AI sub-processors as described in Section 2A and our Data Processing Agreement; bulk client data, full general ledgers, and persistent analytical state never leave our infrastructure.

The Opagio Platform is hosted on Google Cloud Platform (Firebase), which maintains SOC 1, SOC 2, SOC 3, and ISO 27001 certifications. Our infrastructure benefits from:

• Data centre physical security (biometric access, 24/7 monitoring, environmental controls).
• Network security (firewalls, intrusion detection, DDoS protection).
• Automated infrastructure patching and vulnerability management.
• Redundant storage with automated backups.
• Database-level delete protection to prevent accidental or unauthorised database deletion.

Data Residency

All customer data is stored in European data centres. Our primary database is hosted in the Google Cloud eur3 multi-region (Europe), which spans data centres in London (United Kingdom), Belgium, and the Netherlands. This ensures that all customer data at rest remains within the European Economic Area (EEA) and the United Kingdom. No international transfers outside the EEA are required for core platform operations.

2. Encryption

All data is encrypted both in transit and at rest:

• In Transit: All connections to opag.io use TLS 1.2 or higher. We enforce HTTPS across the entire platform with HSTS (HTTP Strict Transport Security) headers.
• At Rest: All data stored in our databases and file systems is encrypted using AES-256 encryption managed by Google Cloud.

2A. AI and Automated Processing Security

Our Classification Engine combines rule-based algorithms and proprietary classification models that run within our own infrastructure with selective use of vetted third-party large language model ("LLM") sub-processors for tasks that genuinely require them:

• In-house first. Rule-based classification, deterministic mapping, and proprietary models execute within our Google Cloud environment. The majority of automated processing on your financial data does not leave the platform boundary.
• LLM sub-processors for narrow tasks. For features that require general-purpose language understanding — summarisation, semantic search across uploaded documents, structured extraction from unstructured client materials, and natural-language interpretation — we transmit limited, task-specific extracts of your data to vetted enterprise AI providers. Current AI sub-processors are listed in our Data Processing Agreement.
• Contractual protections. All AI sub-processors are bound by enterprise data-processing agreements that prohibit use of your data to train, fine-tune, or otherwise improve their general-purpose models, and require deletion of your data after the request lifecycle (subject only to short, non-training operational retention windows for abuse-prevention and debugging, as standard for enterprise AI APIs).
• Model isolation. Our own classification models are versioned and auditable. Model updates are tested in isolated environments before deployment and do not retroactively change previously generated outputs.
• Self-hosted inference roadmap. We are developing a self-hosted inference layer that will let us perform an increasing share of LLM-class tasks within our own infrastructure, reducing dependency on third-party AI sub-processors over time. This work is sequenced behind publication of our patent (GB2607796.6) and is scheduled to begin reducing third-party LLM scope from 2027.

3. Application Security

Our application layer implements multiple security controls:

• Authentication and Access Control: Platform authentication is provided by Supabase Auth with the following security measures: JWT-based sessions with configurable expiry and token rotation; authentication resilience via keep-alive connections, local JWT verification fallback, and strict timeouts to ensure service continuity during upstream provider interruptions; organisation-scoped data access — all API endpoints derive organisation identity from the authenticated session, never from client-supplied parameters; API key access with cryptographic prefix validation, exact length enforcement, and automatic expiry/revocation checks; and admin access controlled by explicit allowlist, separate from standard authentication.
• CSRF Protection: All state-changing requests are protected against cross-site request forgery.
• Content Security Policy: Every response carries a Content Security Policy. It confines scripts, styles, fonts, frames, and outbound connections to our own origin plus a named allowlist of service providers (Stripe, Google Fonts, Google Tag Manager, and Supabase), blocks object and plugin embedding (object-src 'none') and inline event handlers (script-src-attr 'none'), restricts who may frame our pages (frame-ancestors 'self', reinforced by X-Frame-Options: DENY), pins the document base URI and form targets to our own origin, and upgrades insecure requests. The policy currently permits inline scripts and styles, so it limits the impact of cross-site scripting rather than eliminating it.
• Rate Limiting: Endpoints that change data are rate-limited to prevent abuse and brute-force attacks, and an automated check in our continuous integration pipeline flags any such endpoint added without one. Two endpoints that change nothing are documented exceptions — signing out, which clears only the caller's own session cookie, and a retired search-engine ping that returns an acknowledgement and nothing else — as are our webhook endpoints, which verify a cryptographic signature on every request instead.
• Input Validation: User-supplied input is validated, length-capped, and sanitised server-side, and user-origin text is escaped where it is rendered into a page. Our application data is held in Google Cloud Firestore and accessed through the Firebase Admin SDK, which takes field names and values as typed parameters rather than assembled query strings; we operate no SQL database, so there is no SQL injection surface.
• Security Headers: We deploy comprehensive HTTP security headers including X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.

4. Access Control

• Principle of least privilege applied to all internal systems.
• Role-based access control (RBAC) within the Platform.
• Production environment access restricted to authorised personnel only.
• API keys and secrets managed through environment variables, never stored in source code.
• Secret rotation on a regular schedule (minimum every 90 days).

5. Development Security

• All code changes go through peer review before deployment.
• Automated CI/CD pipeline with security checks, linting, and testing.
• Dependency vulnerability scanning (npm audit) on every build.
• Test and production environments are completely separated.
• No customer data is used in test environments.

Penetration Testing. We commission annual penetration testing by qualified third-party security assessors. Our most recent internal security audit was conducted in April 2026, with findings tracked and remediated through our security audit programme. Summary results are available to enterprise clients under NDA.

We also conduct continuous automated security scanning as part of our CI/CD pipeline, including dependency vulnerability scanning (npm audit) and static analysis.

6. Incident Response

We maintain a documented incident response plan that includes:

• Defined severity classification (P1 critical through P4 low).
• Assigned incident response roles and escalation procedures.
• 24-hour client notification for data breaches (per our DPA).
• 72-hour notification to the ICO for qualifying personal data breaches.
• Post-incident review and remediation tracking.

Annual tabletop exercises are conducted to test our incident response readiness.

7. Data Protection

• Daily automated backups: Automated daily backups with 7-day retention, managed by Google Cloud. Restoration procedures are tested regularly.
• Point-in-Time Recovery (PITR): Enabled with a 7-day recovery window, providing near-zero recovery point objective (RPO). This allows restoration to any specific point within the preceding 7 days in the event of data loss or corruption.
• Delete protection: Database-level delete protection is enabled to prevent accidental or unauthorised deletion of the entire database.
• Data retention policies enforced programmatically (see our Privacy Policy for specific periods).
• Deleted data is purged from backups within 7 days of primary deletion, with a 90-day maximum guarantee.
• Data export available in machine-readable formats (JSON, CSV) on request.

8. Compliance and Certification Roadmap

9. Responsible Disclosure

We welcome responsible security research. If you discover a vulnerability in our Service, please report it to security@opag.io.

We commit to:

• Acknowledging your report within 3 business days.
• Providing an initial assessment within 10 business days.
• Not pursuing legal action against good-faith security researchers.

For our full responsible disclosure policy, see /.well-known/security.txt.

10. Contact

Security team: security@opag.io

Privacy matters: privacy@opag.io

Opagio Ltd, registered in England & Wales, company number 13050381.