# Vendor assessment **Summary:** Unless's answers to standard vendor due diligence and security questionnaires, covering company and contracts, privacy and personal data, security controls, sustainability, artificial intelligence, and a detailed application security self-assessment. All statements are public and verifiable against our legal documents. **In short:** Our answers to standard vendor and security questionnaires, in one public place. **Last updated:** 2026-06-18 This page brings together the answers Unless gives to vendor due diligence and security questionnaires. It covers our company and contracts, privacy and personal data, security controls, sustainability, artificial intelligence, and a detailed application security self-assessment. All statements here are public. Where a question would normally point to a contract such as a Master Subscription Agreement, we instead point to the matching public document on our website, so anyone can verify the claim without a signed agreement in hand. Customer names and personal contact details have been removed. For the source documents that back up these answers, see: - [Data and locations](https://unless.com/en/legal/resources/data-and-locations/) - [Data processing addendum](https://unless.com/en/legal/customers/data-processing-agreement/) - [Security addendum](https://unless.com/en/legal/customers/security-addendum/) - [Sub-processors](https://unless.com/en/legal/customers/sub-processors/) - [Certifications](https://unless.com/en/legal/company/certifications/) - [EU AI Act compliance](https://unless.com/en/legal/resources/eu-ai-act-compliance/) - [Terms of service](https://unless.com/en/legal/customers/terms-of-service/) - [Code of conduct](https://unless.com/en/legal/company/code-of-conduct/) - [Trust overview](https://unless.com/en/trust/) ## 1. Company and contracts ### 1.1 What we provide Unless is a compliance-first, AI-native customer agent platform built for regulated European businesses. One agent covers acquisition, retention, expansion, and support across the whole customer journey, with a full audit trail behind every decision. We combine agentic AI, no-code configuration, and built-in governance so our customers can raise revenue, lower support costs, and run compliant customer experiences around the clock. We work with enterprise customers under a Master Subscription Agreement, which includes a data processing addendum, a security addendum, and an EU AI Act appendix. The public versions of these documents are linked above and reflect the same commitments described here. ### 1.2 Certifications and audit reports Our cloud infrastructure and key components are certified through our providers. As a certified AWS Partner, we passed the AWS Foundational Technical Review, including its Sustainability Pillar, on infrastructure certified for compliance with ISO/IEC 27001:2013, 27017:2015, 27018:2014, and ISO/IEC 9001:2015. These certifications are carried out by independent third-party auditors. The ISO/IEC 27001:2013 certification for AWS covers the AWS security management processes and data centers that form the basis of our service. We also have access to independent third-party examination reports that show how our AWS infrastructure meets key compliance controls, namely SOC 1, SOC 2 Security, Availability and Confidentiality, SOC 2 Privacy Type I, and SOC 3. For security reasons, we cannot send copies of the SOC reports to third parties, but a public information security policy description and a public security addendum are available to everyone. On top of this, we run an information security management approach modelled after ISO 27001 and 27002:2022, and we monitor AI-relevant standards such as ISO/IEC TR 24028 on AI trustworthiness. We are working toward ISO/IEC 42001 certification for AI management systems. ### 1.3 Liability insurance Unless has liability insurance in place that covers liability arising from our customer contracts. Specific insured amounts are addressed in the contract itself rather than on this public page. ### 1.4 Sanctions Neither Unless nor our supply chain, including subcontractors, partners, and owners, is situated in a sanctioned nation or considered a sanctioned entity by the EU. ## 2. Privacy and personal data ### 2.1 Does the service process personal data Yes, the service may involve processing of personal data, depending on what our customers or their end users put in. Processing only happens to deliver the service and is kept limited, as set out in our data processing addendum. By default the personal data we process is minimal and limited to what is needed to operate the service, such as technical identifiers, usage data, and optional contact details for business users. The AI does not require identifiable end-user data to work. Richer personal data, such as CRM records or free-text input that happens to contain personal information, is only processed if a customer chooses to import it or an end user provides it during a conversation. Filtering and tokenization remove coincidental input of personal data. ### 2.2 Data protection contact Privacy matters are overseen by our Data Protection Officer, reachable at dpo@unless.com. ### 2.3 Sub-processors Our official sub-processor list is part of the data processing addendum and is published on our website. The current sub-processors are: For application services that may include user and end-user data: - Amazon Web Services, hosting and storage, EU. - Microsoft Azure, cloud services, EU. - Google Cloud Platform, cloud services, EU. Strictly for the Unless dashboard and our own administration, not the platform: - Stripe, payment provider for customers only, US. - Chargebee, automated subscription billing for customers only, US. - HubSpot, CRM and customer support messaging, EU. Where a sub-processor involves a transfer outside the EEA without an adequacy decision, we put in place an appropriate transfer mechanism under Chapter V of the GDPR, with Standard Contractual Clauses as the default, and we run a transfer impact assessment beforehand. ### 2.4 Hosting location All personal data related to the Unless platform is hosted solely within the European Union, on EU-based infrastructure. The main hosting location is the AWS Ireland region, and auxiliary EU cloud services may process data in other EU regions. Only our own invoicing and financial administration uses tools that may sit partly in the US, and those hold business contacts rather than end-user personal data. It is possible, and it is our standard, to host all platform personal data within the EU and EEA. ### 2.5 Data classification We maintain a data classification policy that sorts data by sensitivity and business impact, with matching handling, access, and protection rules for each class. Customer data processed on the platform is treated as confidential, our strictest class. Confidential data is protected by encryption at rest and in transit, role-based access on a need-to-know basis, multi-factor authentication for privileged access, EU-only hosting, audit logging, and contractual protection through the agreement. ### 2.6 Transfers without an adequacy decision We do not transfer platform personal data to countries without an applicable adequacy decision as a matter of course. Where any onward transfer would occur, the mechanism and transfer impact assessment described in section 2.3 apply. ### 2.7 Government access requests We have not received requests from non-EU or non-EEA governments for access to customers' personal data. ### 2.8 Data breaches The service has not experienced any significant personal data breaches in the last three years. ## 3. Security The answers in this section apply to the systems, processes, and people involved in delivering our service, and to our organization as a whole. ### 3.1 Data classification See section 2.5. Customer data is classified as confidential and handled under our strictest controls. ### 3.2 Multi-factor authentication Multi-factor authentication is enforced for all Unless personnel who can reach systems or environments holding customer data. This covers cloud consoles, internal administrative tools, and the management dashboard, on top of strong password policies and, where used, single sign-on with centrally managed identities. Privileged accounts face extra controls such as short-lived credentials and stricter authentication. ### 3.3 Role-based access control We provide role-based access control so customers can limit their own people to need-to-know information. Inside the dashboard, users can be assigned to roles or teams with set permissions, and access to specific projects, assistants, or data sets can be restricted. Sensitive areas such as configuration, integrations, and compliance settings are reserved for higher-privileged roles. Access can be adjusted over time and revoked immediately when someone's responsibilities change. For end users, we offer similar control based on secure identification with a backend-signed token, audiences, and shielded taxonomy trees, so information only reaches the right people. ### 3.4 Backup and recovery We run automated backups of our production databases and critical configuration at regular intervals, stored redundantly within our cloud environment. Backups are encrypted and used in periodic restore tests so we can confirm reliable recovery after corruption, accidental deletion, or a broader incident. Continuous database backups are retained for thirty-five days. ### 3.5 Password strength For accounts that use local login, we require complex passwords with a minimum length, a mix of character types, and avoidance of common patterns, and we encourage unique credentials per user. Administrative and other sensitive accounts must also use multi-factor authentication. Single sign-on is not a feature we provide ourselves, but we support several federated identity providers if a customer wants that. User passwords are at least twelve characters and include uppercase, lowercase, numbers, and special characters. ### 3.6 Credential storage When we manage authentication credentials, we use industry-standard secure methods. User passwords are never stored in plain text; they are salted and hashed with strong password-hashing algorithms and protected by additional encryption at rest. Other secrets, such as API keys and tokens, sit in dedicated secret-management systems with strict access controls, auditing, and rotation. ### 3.7 Security incidents The service has not experienced any significant security breaches in the past three years. ### 3.8 Supporting documentation The documentation behind these answers is published online. Relevant resources include the data and privacy, data processing addendum, data and locations, end-user tracking, security addendum, and security risk mitigation pages on our website. ### 3.9 Access to customer environments Our personnel cannot access a customer account or environment without case-by-case authorization. Customers grant and revoke permission for our support team to access their environment from the account section of the product. ### 3.10 ISO 27001 Unless does not hold its own ISO 27001 certification as a legal entity. Our cloud infrastructure is certified through our providers, as described in section 1.2. We also follow an information security management approach modelled after ISO 27001 and 27002:2022, with senior management support and documented, organization-wide policies that are centrally maintained and regularly updated. ### 3.11 Security governance We operate an information security management system modelled after ISO 27001 and 27002:2022, with senior management support and a documented, organization-wide information security policy kept aligned with ISO 27001:2022. ### 3.12 Information risk management We maintain a documented and approved information risk management framework and use it for regular risk assessments of our key business and IT activities. We identify information assets, threats, and vulnerabilities, assess likelihood and impact, then define and track mitigating controls with owners and timelines. Assessments are revisited on a recurring basis and whenever there are major changes, such as new features, infrastructure changes, or new vendors. ### 3.13 Asset management We keep structured inventories for major asset classes, including infrastructure components, core application services, and critical third-party services, stored centrally and updated whenever assets change. We also maintain a Software Bill of Materials for the platform. Important assets such as access lists and password policies are reviewed monthly, while certain aggregated reports are reviewed quarterly. ### 3.14 Vulnerability management We manage vulnerabilities through regular assessments, monitoring, and timely remediation. Recurring scans and security reviews run on our infrastructure and application, with findings tracked in an internal register with owners and deadlines. Critical issues are remediated immediately and lower-risk items within defined SLAs. We follow a structured patch process and use defense-in-depth measures such as hardened configurations and least-privilege access between patch cycles. ### 3.15 Security testing We run regular vulnerability scanning and security testing across our infrastructure and application. Automated scans run continuously through our CI pipeline and provider-native security services, with findings tracked by severity. Critical and high-severity issues are remediated immediately and lower-severity items within defined timelines. We also run periodic security reviews and engage external expertise for targeted penetration testing on significant changes or major releases. At our most recent assessment cycle, no critical or high-severity findings remained unresolved, all identified issues were remediated within their SLAs, and no finding led to a material security incident or data exposure. For confidentiality reasons we do not share full penetration test reports, but we can discuss specific control areas under NDA. ### 3.16 Training Our people receive regular, role-specific training on data protection and security. New team members complete onboarding training on security policies, acceptable use, confidentiality, and privacy. After that, staff follow recurring awareness training that is updated as threats and regulations change, with deeper modules for roles that have elevated access. Topics include secure development, access control, handling personal data, incident reporting, and phishing. Completion is tracked. ### 3.17 People management We screen new employees, reinforce security responsibilities, and manage security through role changes and offboarding. Before hiring, we run appropriate background and reference checks in line with local law and role sensitivity. Responsibilities are reinforced through onboarding, recurring training, and internal guidelines. When someone changes role or leaves, we promptly adjust or revoke access, recover company assets, and keep confidentiality obligations in force. ### 3.18 Incident detection We have incident detection measures to spot and analyze potential threats and breaches. We collect and retain logs from key systems and applications, monitor them for suspicious activity, and use alerts to flag events for investigation. When something is detected, we follow defined triage and incident-handling procedures to assess impact, contain the issue, and gather evidence. ### 3.19 Incident handling We have established routines for handling security incidents and potential breaches, including notification steps. Our incident response process has clear roles and phases: detection, triage, containment, eradication, recovery, and post-incident review. For incidents that may involve personal data or customer impact, we assess severity and regulatory relevance, then notify affected customers without undue delay and within the timelines set out in our data processing addendum, sharing the information they need to meet their own obligations. ### 3.20 Crisis management We maintain a crisis management plan for high-impact events. It defines roles, decision lines, and communication channels for unusual situations such as major outages and broad-impact security incidents. It covers how we prioritize critical services, coordinate our workforce, and invoke fallback procedures to keep essential operations running until normal processes are restored. ### 3.21 Business continuity and disaster recovery We have documented business continuity and disaster recovery procedures covering recovery objectives, roles, and communication flows, and describing how we prioritize and restore critical services and data. They include redundant cloud infrastructure, regular backups and restore testing, and fallback procedures for a degraded but functional mode during recovery. For confidentiality reasons we do not share the full internal documentation, but we can discuss specific elements under NDA. ### 3.22 Network security We use several layers of network security. Our cloud networks use strict security groups and firewalls at the edge and service levels, allowing only necessary traffic. We segment environments, for example separating production from non-production and isolating management interfaces, to limit lateral movement. Traffic runs through managed load balancers and gateway services, and we use provider-native intrusion detection and monitoring to flag and block suspicious patterns. External access to administrative interfaces requires strong authentication and is limited to a minimal set of endpoints and roles. ### 3.23 Cloud security We apply a structured cloud security framework across our AWS-based platform and supporting EU cloud workloads. Roles and responsibilities for configuration, security reviews, and incident response are defined within our ISMS. Access management follows least-privilege principles, using IAM roles, role-based access, MFA for privileged accounts, and short-lived credentials where possible. Data protection includes encryption at rest with cloud-native key management, TLS in transit, and additional PII filtering and tokenization in our retrieval and AI pipelines so raw personal data does not leave controlled storage. We monitor the environment continuously with provider-native logging and our own alerts. ### 3.24 Secure development We follow secure development practices, including reviews, scanning, and patching for our own code and third-party components. Engineers use secure coding guidelines, with mandatory peer review on security-sensitive changes. Automated checks in our CI pipeline cover linting, dependency vulnerability scans, and basic security tests, with findings tracked to resolution. Third-party libraries are monitored for known vulnerabilities and patched within defined SLAs, prioritizing high-severity issues on exposed components. ### 3.25 Access management We have centralized access management for our personnel and systems. Access to production and customer data is strictly role-based, with the minimum permissions needed. Authentication for internal tools and cloud consoles uses strong passwords, enforced policies, and multi-factor authentication, and many paths rely on single sign-on with centrally managed identities. We review access rights regularly and adjust them when people change roles or leave. Administrative and sensitive actions are logged and can be reviewed during investigations. ### 3.26 Physical security Our own team has no direct physical access to data centers; we manage resources remotely through secure, authenticated cloud interfaces. Physical safeguards are provided by the data centers where we host the platform, using layered controls such as perimeter protection, access badges, biometric checks, mantraps, surveillance, and on-site security staff. Hardware sits in controlled environments with power, cooling, and fire protection, and strict procedures for equipment handling and disposal. ### 3.27 Availability We use redundancy at several layers. The core platform runs on AWS in an EU region with multi-availability-zone deployments, so traffic can fail over to healthy instances if one zone has issues. Datastores and message queues use managed, replicated cloud services with automatic failover, and critical components are designed to be stateless or quickly rebuilt from infrastructure-as-code. We perform regular automated backups, store them redundantly, and test restores. ### 3.28 Strong encryption We use strong, industry-standard encryption for data at rest, in transit, and for credentials, with secure key management. At rest, data in our cloud databases and storage is encrypted using AES-256 or equivalent through managed encryption services, and snapshots and backups are encrypted too. In transit, all communication uses TLS with modern cipher suites, with outdated protocols disabled and HTTPS enforced. Passwords are salted and hashed, and other secrets sit in dedicated secret-management services. Encryption keys are managed through cloud key-management services with restricted access, usage auditing, and rotation. ### 3.29 Logging Our application and platform log relevant user and administrator actions for accountability. We log events such as authentication attempts, configuration changes, and access to administrative functions, with timestamps and identifiers so actions trace to specific accounts. Customer dashboards also show an activity history, including actions by our support staff when access has been granted. Logs are protected against tampering and can be queried during investigations or audits. Data retention times are no longer than 365 days, and can be shorter where a customer requires it. Security-relevant logs are monitored continuously through automated alerting and reviewed on a regular cadence, as well as during investigations. ### 3.30 Supply chain security We evaluate our key subcontractors and third-party providers to confirm they meet security standards comparable to our own. Before onboarding, we assess their security posture, including certifications, data protection terms, hosting locations, and technical measures, and only proceed if they meet our requirements. For existing suppliers, we periodically review their documentation and contractual commitments, monitor changes to their status, and adjust our use of their services if anything material changes. ## 4. Sustainability ### 4.1 Codes of conduct We accept supplier codes of conduct that align with widely shared standards on ethics, labor, and environment. We also maintain our own code of conduct, published on our website, which covers the same areas. All the aspects typically covered by such codes are included in our policies. ### 4.2 Disputes We have not been involved in any disputes, investigations, or lawsuits related to corruption, fraud, environment, or human rights in the past three years. ### 4.3 Supplier sustainability and compliance We assess suppliers on sustainability and compliance during selection and ongoing review. Before onboarding, we check public commitments, certifications, and policies to confirm they meet our baseline. For strategic providers, we revisit these materials periodically and monitor for material changes, so we can adjust our use of their services if their practices no longer align with our standards. ### 4.4 Human rights and working conditions We set explicit expectations for suppliers and partners on human rights and working conditions and build them into how we choose and evaluate them. We avoid vendors that do not meet our baseline and watch for material changes such as controversies or policy reversals. As a small company operating under Dutch law, our internal practices already reflect strict standards on these topics, and our main lever is supplier selection. ### 4.5 Diverse and non-discriminatory hiring We handle recruitment case-by-case because our team is small. We believe a diverse team performs better than a homogeneous one, so we shape our hiring approach to keep that balance. ### 4.6 Emission targets We have set emission reduction targets compatible with limiting global warming to 1.5 degrees Celsius and have formally committed them to the Science Based Targets initiative for assessment and validation. ### 4.7 Sustainability reporting We are a small company and currently fall below the thresholds of the relevant reporting regimes, such as the Norwegian Transparency Act and the EU Corporate Sustainability Reporting Directive. We are therefore not legally required to publish a standalone sustainability report, so no public report is available. ### 4.8 Greenhouse gas emissions Our cloud usage on AWS is the only significant part of our footprint by capacity. For 2025, our AWS Customer Carbon Footprint Tool report provides estimated emissions across the full range of AWS products, expressed in metric tons of carbon dioxide equivalent. The tool's methodology follows the GHG Protocol and ISO 14064, the GHG Protocol Product Life Cycle Accounting and Reporting Standard with its ICT sector guidance, and ISO 14040 and 14044 for life cycle assessment. ## 5. Artificial intelligence ### 5.1 Use of AI Yes, the service uses artificial intelligence. As an AI-native platform, we do not keep separate terms for AI features; the same terms of service apply, and they are published on our website. ### 5.2 Provider or deployer Unless is the provider of the AI system under the EU AI Act, and our customer is the deployer. We develop and operate the platform, including its architecture, retrieval layer, Privacy Vault, and integration with foundation models. The underlying general-purpose models are hosted within the environments of our EU cloud sub-processors. We do not transmit customer data directly to separate model vendors, so customer data stays inside the cloud sub-processor boundary. ### 5.3 AI governance AI governance is the core of how we build and operate, not a separate add-on. It aligns with our wider information security and compliance posture, covering our ISMS modelled after ISO 27001 and 27002:2022, the GDPR, DORA, and the EU AI Act, and is reinforced by architecture that constrains what the AI can do. Key points: - AI use is governed by the same ISMS, risk management framework, and incident response processes as the rest of the platform, with senior management ownership. - We act as provider under the EU AI Act, monitor ISO/IEC TR 24028 on AI trustworthiness, and are preparing for ISO/IEC 42001 certification for AI management systems. - Our architecture keeps the AI's role narrow: foundation models only rephrase vetted snippets from customer-approved sources, never train on customer data, and work on tokenized or de-identified data through the Privacy Vault, so raw personal data never reaches model providers. - Human oversight is built in: agentic actions in regulated scenarios require human approval, and customers can configure topic boundaries, audiences, and access rules. - All AI workloads run on EU-hosted infrastructure, with the same encryption, access control, logging, and monitoring as the rest of the platform. - Transparency is supported through public changelogs, in-dashboard release notifications, and contractual documentation. Our public-facing AI and compliance documentation is available on our website, including the data and privacy, security addendum, EU AI Act compliance, security risk mitigation, and code of conduct pages. ### 5.4 Categories of personal data The AI solution can process limited, low-risk personal data, but the architecture keeps AI models from ever seeing raw personal data. We apply several layers: - At ingestion, source content is filtered so obvious personal identifiers are excluded from the material used for AI assistance. - At runtime, user input is filtered again to remove or mask personal data before it enters the AI pipeline. - For personal data that must be processed, for example to personalize a response, we tokenize it and store the mapping in a separate Privacy Vault. The models only see tokens, and responses are de-tokenized afterwards inside our controlled environment. As a result, while the platform may handle contact data, online identifiers, and free text that could contain personal data, the AI models work only on de-identified or tokenized data. ### 5.5 Data flow When an end user sends a message to an assistant, it travels over TLS to our EU-hosted AWS backend. There it first passes through PII filtering and Privacy Vault tokenization, so raw identifiers are never exposed to AI models. The cleaned, tokenized input goes to our retrieval layer, which pulls relevant snippets from EU-hosted vector stores and, where configured, from customer systems through agentic skills, all run from our EU infrastructure. Based on that context, we either call an EU-hosted model to rephrase the answer or route an agentic action that still requires human approval in regulated scenarios. The output returns to our backend, where we de-tokenize through the Privacy Vault, apply safety checks, and stream the final response back over TLS, without sending raw personal data to external model providers. An architecture diagram is available on our trust page. ### 5.6 Bias mitigation We reduce bias risk mainly by limiting model agency and tightly controlling the data the model can act on. The model rephrases vetted snippets from a customer's own documentation rather than making open-ended decisions, which narrows the room for biased inferences. During onboarding we help customers curate and structure source content, with topics, audiences, and confidentiality rules, so assistants do not mix contexts. Agentic skills assist humans rather than replace them in high-impact decisions, and sensitive actions require human review as a bias control point. The platform supports continuous test runs with benchmark questions and expected answers, so customers can monitor quality across scenarios and adjust content or boundaries. Because we do not train custom models on end-user data and avoid broad decision-making authority, residual bias risk is largely tied to the underlying foundation models and the customer's own source material, which this narrow, supervised design contains. ### 5.7 Accountability Responsibility for the AI system is split between Unless as provider and the customer as deployer, in line with the EU AI Act and our contracts. As provider, Unless is accountable for: - the design, security, and reliability of the platform, including the retrieval layer, Privacy Vault, agentic framework, and model integrations; - operating the AI system within our ISMS, risk management framework, and incident response processes; - monitoring AI-specific risks such as bias, hallucinations, accuracy, and security, maintaining safeguards like PII filtering, tokenization, topic boundaries, and benchmark testing, and applying updates within defined SLAs; - notifying customers of incidents that may affect their data or service, in line with our agreements; - supporting customers in meeting their own obligations under the GDPR, DORA, and the EU AI Act. Internally, accountability for compliance and privacy sits with our Data Protection Officer, and accountability for technical operation and security sits with engineering leadership. Senior management oversees the ISMS and AI governance. As deployer, the customer remains responsible for: - the lawful basis and appropriateness of using the AI system in their context; - curating source content and configuring topic boundaries, audiences, and agentic skills in their environment; - providing human oversight for sensitive or high-impact decisions; - communicating with end users and handling data subject rights through the controls we provide. If a failure occurs, our incident response and contractual arrangements define how impact is assessed, contained, and communicated, and how remediation responsibilities are shared. ### 5.8 Transparency We focus on transparent components, documentation, and change communication. Our client UI is built on an open-source component framework, so customers can inspect how conversational elements behave. Configuration of assistants, topics, data sources, and agentic skills is explicit and visible in the dashboard. We maintain a public changelog for product and AI changes and share a weekly summary with customers, with significant updates also highlighted inside the dashboard. For enterprise deployments, contractual documentation describes architecture, data flows, and controls in a stable, reviewable form. ### 5.9 Accuracy We use upfront curation, continuous tests, and feedback loops to maintain accuracy. Assistants draw answers from curated sources that the customer approves, with topic boundaries and access rules keeping them to authorized content. Customers can define benchmark questions and expected answers, which we test regularly, surfacing accuracy scores and gaps in the dashboard. End users can flag bad answers, and we aggregate feedback so customers can refine content, prompts, or topics. For agentic skills that propose actions, humans stay in control and can correct outputs before use. ### 5.10 Hallucinations We reduce hallucinations by constraining context and continuously checking outputs. Content is segmented into clear topics, so the AI retrieves snippets only from the right subject area. Answers must be grounded in retrieved, customer-approved sources, and prompts instruct the model to stay within that evidence and ask for clarification when context is ambiguous. Periodic benchmark tests surface cases where the model drifts beyond source material, and end-user feedback helps detect hallucination patterns so customers can adjust topics, documents, or prompt settings. To protect the accuracy of personal data specifically, personal data is either excluded from AI context or tokenized through the Privacy Vault, so models never invent or overwrite raw identifiers. Where personal context is needed, the system retrieves factual data from trusted systems in a read-only way rather than letting the model guess. For agentic skills that touch user records, humans must review and approve changes before they apply. If a person spots inaccurate information, the customer can use built-in access, rectification, and erasure features to correct or remove it. ### 5.11 Data subject rights Data subjects exercise their rights through the customer as controller, using standard GDPR and data subject access request channels that we support technically rather than bypass. - Access and rectification: the controller performs these operations from our dashboards, with a human in the loop on our side to verify. Tokens generated for personal data are orphaned if the underlying value changes, to prevent token hijacking. - Erasure and restriction: the controller requests these from the dashboard, again with a human in the loop to verify. Tokens are orphaned if the underlying value is deleted. - Portability: handled through the same controller-driven flow. The controller initiates the request from the dashboard, and the system exports the relevant personal data in a structured, commonly used, machine-readable format such as JSON or CSV, with a human in the loop to verify. ### 5.12 Training on customer data No. We do not use customer content or usage data to train AI algorithms. Content is improved by suggestions from the customer's support team or by updated business knowledge the customer submits, never from conversations with end users. ### 5.13 AI sustainability We minimize the use of AI models for sustainability, security, performance, and cost reasons, which all point in the same direction. ## 6. Application security self-assessment This section records our self-assessment against a set of application security requirements. Each item lists whether it applies and a short note on how we meet it. ### 6.1 Architecture and data flows - Trust boundaries, components, and significant data flows are documented, with public information available on our security risk mitigation page. - The application avoids unsupported or deprecated client-side technologies; the only client-side technologies are HTML and CSS with modern frameworks such as React. - Access controls are enforced at trusted enforcement points such as gateways, servers, and serverless functions, never on the client. We use AWS services across the infrastructure, including AWS Lambda, and AWS Cognito for authentication and authorization. ### 6.2 Data classification and protection - All sensitive data, such as emails, passwords, and accounts, is identified and classified into protection levels. - Each protection level has matching requirements for encryption, integrity, retention, privacy, and confidentiality, applied in the architecture. We use AWS services such as S3, DynamoDB, and Redshift, all encrypted. - Regulated private data, including personal data likely subject to the GDPR, is encrypted at rest, supported by encryption across the AWS services we use. ### 6.3 Integrity and supply chain - The application uses integrity protections and does not load or execute code from untrusted sources. We enforce strict dependency rules, verify that package content matches expected hashes in the lockfile during installation, and run security auditing. - Build and deployment are secure and repeatable through CI and CD automation, managed in GitLab, with every build and deployment automated. - The application, configuration, and dependencies can be redeployed from documented automated scripts or restored from backups in a timely way. All configuration is committed in version control or handled by AWS services. - Administrators can verify the integrity of security-relevant configurations to detect tampering, using AWS CloudTrail. - Debug modes are disabled in production, handled automatically by our build framework. ### 6.4 Domain and network protections - The application is protected against subdomain takeovers, with regular checks for DNS changes or expiry. All domains are managed in Route 53. - Anti-automation controls guard against excessive calls and denial-of-service attempts, using built-in rate limiting in AWS API Gateway. ### 6.5 File handling - We do not store untrusted files on a web server; the site is fully static and hosted on S3, so there is no web root. Files uploaded by users are stored in a separate S3 bucket. - Files from untrusted sources are scanned for malicious content using AWS GuardDuty Malware Protection for S3. ### 6.6 API and authorization - API URLs do not expose sensitive information such as API keys or session tokens. - Authorization decisions are enforced at both the URI level, through the controller or router, and the resource level, through model-based permissions. - Only valid RESTful HTTP methods are enabled, preventing actions such as normal users issuing DELETE or PUT on protected resources. - The Origin header is not used for authentication or access control. ### 6.7 Authentication and sessions - User-set passwords are at least twelve characters and include a number, a special character, an uppercase letter, and a lowercase letter. - System-generated passwords are securely random, expire after seven days, and cannot become long-term passwords. - Passwords are salted, hashed, and stored to resist offline attacks, managed by AWS Cognito. - There are no shared or default accounts such as root or admin. - Lookup secrets are single-use. - Out-of-band authentication requests, codes, or tokens expire after ten minutes; we use Cognito and SNS to send SMS for MFA codes. - Initial authentication codes are generated by a secure random number generator with sufficient entropy, handled by AWS Cognito. - Logout and expiration invalidate the session token, preventing session resumption, handled by AWS Amplify with Cognito. - After a password change, users can terminate all other active sessions, managed by Cognito. - The application uses session tokens rather than static API secrets, except in any legacy paths. - A full, valid login session is required before sensitive transactions or account modifications. - Administrative interfaces use multi-factor authentication, which is required for all our users to reach management interfaces. ### 6.8 Access control - Access control rules are enforced on a trusted service layer on the backend, so client-side controls cannot be bypassed. - User and data attributes used by access controls cannot be manipulated by end users unless specifically authorized. - The principle of least privilege applies, limiting users to resources they are authorized for, with protection against spoofing and privilege elevation. - Access controls fail securely, including during exceptions. - Sensitive data and APIs are protected against insecure direct object reference attacks. We check user permissions on the backend against the object being changed, and we use UUIDs rather than incremental IDs. ### 6.9 Input and output handling - The application defends against HTTP parameter pollution. - User input is sanitized before being stored or passed to external services, including mail systems, protecting against SMTP and IMAP injection. - The application avoids dynamic code execution. The one exception is a configurable component action that runs on component close; this configured code is sanitized and can only be changed by a trusted, logged-in account with the required privileges. - The application protects against server-side request forgery by validating and sanitizing untrusted data and metadata, using allow lists for protocols, domains, paths, and ports. - User-supplied SVG content is sanitized or sandboxed to prevent cross-site scripting; user SVG is used only as a background image, which makes script execution impossible. - Output encoding matches the interpreter and context, with specific encoders for HTML, attributes, JavaScript, URLs, headers, and other contexts. - The application protects against JSON injection, JSON eval attacks, and JavaScript expression evaluation. - LDAP injection is not applicable; we do not use LDAP. ### 6.10 Cryptography - Cryptographic operations are constant-time, with no short-circuit operations in comparisons, calculations, or returns. - Random GUIDs use the version 4 algorithm with a cryptographically secure pseudo-random number generator. - Key material is not exposed to the application and is handled in an isolated module. We use the Web Crypto API in the browser where applicable and the built-in Crypto functionality in Node on isolated AWS Lambda functions. ### 6.11 Logging and data protection in transit - The application does not log credentials or payment details, and session tokens are stored only in irreversible, hashed form. - Sensitive data is not cached in server components such as load balancers and application caches. - Browser storage, including localStorage, sessionStorage, IndexedDB, and cookies, does not contain sensitive data. - Sensitive data is sent in the HTTP message body or headers, never in query string parameters. - Access to sensitive data is audited without logging the data itself, in line with data protection requirements. - Connections use trusted TLS certificates managed in AWS Certificate Manager; we do not use self-signed certificates. - Certificate revocation, such as OCSP stapling, is enabled and managed by AWS Certificate Manager.