Security at ARIA

1. Our security program

Security and privacy are built into how QED Ltd designs, builds and operates ARIA, rather than added at the end. We run a risk-based security program aligned to recognised frameworks, including the principles behind SOC 2, ISO 27001 and the GDPR, and we apply controls in proportion to the sensitivity of the data and the risks involved.

The program has clear ownership within the company, with named individuals accountable for security, privacy and compliance. We review our controls, threats and priorities on a regular basis so that our protections keep pace with how the product and our customers change.

• Defence in depth, least privilege and secure defaults applied across the product and infrastructure.
• A risk-based approach that prioritises the controls that most reduce real-world risk.
• Defined ownership and a regular review cadence so the program improves over time.

2. Governance, policies and risk management

We maintain a set of documented security and privacy policies that define how we handle data, manage access, build software and respond to incidents. These policies are reviewed periodically and updated as our environment, regulations and threats evolve.

We carry out regular risk assessments to identify, evaluate and treat security and privacy risks. Findings are tracked to resolution, and management is accountable for the program, including approving policies and reviewing the status of significant risks on an internal review cadence.

• Documented policies covering data protection, access, secure development and incident response.
• Periodic risk assessments with findings tracked through to remediation.
• Internal review cadence and management accountability for the program.

3. Infrastructure and hosting

ARIA runs on reputable cloud providers that operate certified data centres with strong physical and operational security. We rely on these providers for physical access control, environmental protection and hardware lifecycle management, and we build our own controls on top of their platforms.

We separate our development, staging and production environments so that work in progress cannot affect live customer data. Infrastructure is defined and deployed as code, which gives us repeatable, reviewable changes and hardened baseline configurations for the systems that run the service.

• Hosting on reputable cloud providers operating certified data centres.
• Segregation between development, staging and production environments.
• Infrastructure as code with hardened baseline configurations.

4. Encryption

Data in transit is encrypted using TLS 1.2 or higher between our customers, ARIA and the services we depend on. Data at rest is encrypted using AES-256 across our primary data stores and backups.

Encryption keys are managed using a dedicated key management service, with access restricted and keys rotated on a defined schedule. Enterprise customers can use customer-managed keys where they want direct control over the keys that protect their data.

• TLS 1.2 or higher for data in transit.
• AES-256 for data at rest.
• Managed key storage with rotation, and customer-managed keys for enterprise.

5. Identity, authentication and access control

Access to systems and data follows the principle of least privilege, granted through role-based access control so that people and services hold only the permissions they need. Customers can connect their own identity provider using SSO and SAML to manage who can sign in to ARIA.

Our staff authenticate with multi-factor authentication, and access to production systems is granted on a just-in-time basis and reviewed on a regular schedule. Access to sensitive systems and data is recorded through complete audit logging, which can be exported to a customer SIEM on enterprise plans.

• Least privilege and role-based access across systems and services.
• SSO and SAML for customers, multi-factor authentication for staff.
• Just-in-time, reviewed access and complete audit logs, exportable to a SIEM on enterprise plans.

6. Application security and secure development

We follow a secure software development lifecycle in which security is considered at each stage, from design through to release. Changes are subject to peer code review before they reach production, and our pipelines include automated dependency and secret scanning to catch known vulnerabilities and accidental credential exposure early.

We use static and dynamic application security testing to find weaknesses in our code and running services, and we engage independent third parties to perform periodic penetration testing. Issues are triaged by severity and remediated against defined service-level targets, with the most serious issues addressed first.

• Secure SDLC with mandatory peer code review.
• Automated dependency and secret scanning, plus static and dynamic testing.
• Periodic third-party penetration testing and remediation SLAs by severity.

7. Tenant isolation and data segregation

ARIA keeps each customer logically isolated from every other customer. Requests are scoped to a single tenant, so one customer cannot read or affect another customer's data, content or configuration.

Within a customer, ARIA uses permission-aware retrieval so that users only receive answers drawn from the content they are entitled to see. Access rights from connected sources are respected at query time, which prevents answers from leaking information beyond a user's permissions.

• Logical isolation between customers, with access scoped to a single tenant.
• Permission-aware retrieval so users only see what they are entitled to.

8. Data residency and retention

By default, customer data is stored in the EU. For enterprise customers with specific residency requirements, we can support storage in other regions.

Customers control how long conversation data is retained, within the options available on their plan. On request, or when an account is closed, we delete customer data within a stated window, subject to any legal or regulatory obligations that require us to retain certain records.

• EU storage by default, with other regions available for enterprise.
• Customer control over conversation retention.
• Deletion within a stated window on request or account closure.

9. AI and data handling

Customer Content is not used to train shared or third-party foundation models. Your content stays your content, and it is used to serve your own deployment rather than to improve models that other organisations rely on.

Where ARIA relies on external model providers, those providers operate under data processing agreements that include no-retention terms for the content we send them. To improve accuracy, ARIA grounds answers in your approved content and applies citation controls, which reduces inaccurate or fabricated output.

• Customer Content is not used to train shared or third-party foundation models.
• Model providers operate under data processing agreements with no-retention terms.
• Grounding and citation controls reduce inaccurate output.

10. Subprocessors and vendor management

We use a limited set of vetted subprocessors to help deliver ARIA, each engaged under a data processing agreement with appropriate security and confidentiality obligations. A current list of subprocessors is available, and we provide advance notice of material changes so customers can review them.

Before we onboard a vendor or subprocessor, and periodically afterwards, we carry out vendor risk reviews that consider their security posture, data handling practices and relevant certifications.

• Vetted subprocessors engaged under data processing agreements.
• Current subprocessor list available, with advance notice of changes.
• Vendor risk reviews at onboarding and on a recurring basis.

11. Logging, monitoring and threat detection

We collect logs centrally from across our services and infrastructure, and we monitor security-relevant events continuously. Alerts are configured for suspicious or anomalous activity so that our team can investigate and respond quickly.

• Centralised logging across services and infrastructure.
• Alerting and continuous monitoring of security-relevant events.

12. Incident response and breach notification

We maintain a documented incident response plan that defines how we detect, triage, contain, investigate and recover from security incidents. The plan assigns clear roles and responsibilities so that the right people are engaged quickly when an incident occurs.

If an incident affects customer data, we notify affected customers without undue delay and within the timeframes required by applicable law, including the GDPR and UK GDPR. Our notifications aim to give customers the information they need to understand the impact and take their own action.

• Documented incident response plan with defined roles.
• Notification to affected customers without undue delay and within legally required timeframes.

13. Business continuity, backups and disaster recovery

We take regular encrypted backups of critical data so that we can recover from data loss or corruption. We test restoration to confirm that backups are usable, and we maintain recovery objectives that set targets for how quickly we aim to restore service and how much data we aim to recover.

• Regular encrypted backups of critical data.
• Tested restoration and defined recovery objectives.

14. Vulnerability management and responsible disclosure

We welcome reports of suspected security vulnerabilities. If you believe you have found an issue, please report it to security@qedcode.io with enough detail for us to reproduce and assess it.

We ask that you act in good faith, avoid accessing or modifying data that is not yours, avoid disrupting our services, and give us reasonable time to investigate and remediate before any public disclosure. We will not pursue legal action against good-faith researchers who follow this policy.

• Report suspected issues to security@qedcode.io.
• Act in good faith and allow reasonable time to remediate.
• We will not pursue good-faith researchers who follow this policy.

15. Personnel security

Where lawful, we carry out background checks before staff join, and all personnel are bound by confidentiality obligations covering the data they may handle. Staff complete security and privacy training when they join and on a recurring basis, so that good practice stays current across the team.

• Background checks where lawful, and confidentiality obligations for all staff.
• Recurring security and privacy training.

16. Compliance and certifications

Our SOC 2 Type II examination is in progress, and our practices are aligned with the GDPR and UK GDPR. ISO 27001 certification is on our roadmap as the program matures.

Supporting documentation, including reports and security questionnaires, is available to enterprise customers under a non-disclosure agreement.

• SOC 2 Type II in progress, with GDPR and UK GDPR alignment.
• ISO 27001 on the roadmap.
• Documentation available under NDA to enterprise customers.

17. Shared responsibility

Security is a shared responsibility. QED Ltd is responsible for securing the ARIA platform, including its infrastructure, application code, encryption, isolation between customers and the operational controls described in this overview.

Customers are responsible for how they use ARIA within their own organisation, including managing their users and access, choosing what content to connect, and configuring the product appropriately for their needs.

What QED Ltd secures

• The platform, infrastructure, application security, encryption and tenant isolation.
• Monitoring, incident response and the operational controls in this overview.

What customers are responsible for

• Managing their own users, roles and access.
• Choosing connected content and configuring the product for their needs.

18. Enterprise options

For organisations with stricter requirements, we offer additional options including on-premise and private cloud deployment, customer-managed keys, and private or custom models. Enterprise engagements can also include a dedicated security review and a service-level agreement.

You can find more detail on our Enterprise page.

• On-premise and private cloud deployment.
• Customer-managed keys and private or custom models.
• Dedicated security review and SLA.

19. Contact

To report a security concern or suspected vulnerability, contact us at security@qedcode.io. For enterprise security questions, including requests for documentation under NDA, please use our Enterprise page.

If you are evaluating ARIA and need help with a security review, we are glad to support the process and answer your questions.