Home · Legal · Trust & Security Annex
Appendix 3

Trust & Security Annex

This document is published online and incorporated by reference into the Howspace Order Form signed by the Customer. No separate signature is required.

Version v2026.1
Effective 1 May 2026
Permalink legal.howspace.com/legal/trust-security/v2026.1/

Purpose of this annex

Capitalised terms have the meaning given in the Master Subscription Agreement (the "MSA") unless otherwise stated.

This Trust & Security Annex sets out the Supplier's binding commitments to the Customer in respect of (i) service availability, (ii) information-security controls (the "Technical and Organisational Measures" or "TOMs"), (iii) business continuity and disaster recovery, and (iv) the use of artificial intelligence within the Service. It forms an integral part of the Agreement.

01

Service level agreement

1.1

Definitions. In this section 1:

"Monthly Uptime Percentage" means the percentage obtained by dividing (a) the total minutes in the relevant calendar month, less the Unavailable Minutes for that month, by (b) the total minutes in that calendar month, expressed as a percentage.

"Unavailable Minutes" means the number of minutes during the relevant calendar month during which the production instance of the Application is not generally accessible to the Customer's authorised users, excluding any Excluded Downtime.

"Excluded Downtime" means downtime attributable to: (i) scheduled maintenance windows announced in advance on the Supplier's public status page (https://status.howspace.com); (ii) emergency maintenance reasonably required to address a security or stability issue; (iii) a Force Majeure Event; (iv) failure of the Customer's own network, hardware, software or third-party services; (v) misuse of the Service by the Customer in breach of the Agreement; or (vi) suspension by the Supplier in accordance with the Agreement (for example for non-payment after notice).

1.2

Availability target. The Supplier targets a Monthly Uptime Percentage for the Application of 99.8%.

1.3

Service credits. If, in any calendar month, the Monthly Uptime Percentage falls below 99.8%, the Customer is entitled, on written request submitted within thirty (30) days after the end of that month, to a service credit calculated as a percentage of the Service Fees attributable to the affected Service for that month, as follows:

Monthly Uptime Percentage Service credit
< 99.8% and ≥ 99.0% 5% of monthly Service Fees
< 99.0% and ≥ 95.0% 10% of monthly Service Fees
< 95.0% 25% of monthly Service Fees
1.4

Credit cap. Service credits in any calendar month are capped at thirty per cent (30%) of the Service Fees attributable to the affected Service for that month. Service credits are the Customer's sole and exclusive financial remedy for failure to meet the availability target, except as provided in section 1.5.

1.5

Chronic-failure termination. If the Supplier fails to meet the 99.8% availability target in three (3) or more calendar months in any rolling six-month period, the Customer may terminate the affected Service on thirty (30) days' written notice, and the Supplier shall refund the pro-rated portion of any pre-paid Service Fees attributable to that Service for the period after termination takes effect.

1.6

Status page. The Supplier maintains a public status page at https://status.howspace.com with real-time visibility into the status of the production environment and historical incident records.

02

Certifications and assurance

2.1

ISO/IEC 27001:2022. The Supplier shall maintain throughout the Term a certified Information Security Management System under the ISO/IEC 27001:2022 standard, covering the development, provision and management of the Howspace platform. The Supplier shall make a current copy of its ISO/IEC 27001 certificate available to the Customer on written request.

2.2

Howspace Control Framework. The Supplier operates an internal control framework (the "Howspace Control Framework" or "HCF"), built on ISO/IEC 27001:2022 and tested against NIST SP 800-171 and the SOC 2 Trust Services Criteria. The HCF is the Supplier's internal source of truth for security controls. The Supplier does not maintain a SOC 2 Type I or II report as of the Effective Date; the Supplier may, in its sole discretion, obtain a SOC 2 Type I or II report in the future and shall publish that fact through the means set out in section 2.4.

2.3

Cloud-provider assurance. Hosting infrastructure for the Application is provided by AWS, which maintains ISO/IEC 27001 and SOC 2 Type I or II reports. Physical security controls for the production environment are inherited from AWS and validated annually through the Supplier's review of AWS compliance reports, as set out in section 3.7.

2.4

Trust Center. The Supplier publishes its current certifications, security documentation and sub-processor list at https://trust.howspace.com (the "Trust Center"). The Customer acknowledges that the Trust Center is an informational resource; the binding commitments of the Supplier are those set out in the Agreement.

03

Technical and organisational measures (Article 32 GDPR)

The Supplier maintains the following TOMs in connection with the Service. Specific configurations and supporting tooling may evolve in line with the HCF; the Supplier shall not, by way of such evolution, materially diminish the protections set out below without the Customer's prior written consent.

3.1 Governance, risk and policy

  • A documented Information Security Management System ("ISMS") aligned with ISO/IEC 27001:2022, reviewed at least annually.
  • A Security Steering Committee including senior leadership accountable for the ISMS.
  • Continual risk assessments to identify and mitigate threats to the confidentiality, integrity and availability of the Service.

3.2 Personnel security and training

  • Mandatory background and identity checks for all personnel prior to joining, to the extent permitted by applicable law.
  • Ongoing security-awareness training for all personnel, including specialised modules on AI usage and phishing defence.
  • Confidentiality and non-disclosure obligations as a condition of every employment or contractor agreement.

3.3 Identity and access management

  • Need-to-know and least-privilege principles applied to all systems containing Customer Data.
  • Multi-factor authentication (MFA) mandatory for all production and administrative access.
  • Role-based access control aligned with job function; access to internal resources and cloud infrastructure governed by zero-trust principles rather than network location.
  • Centralised identity provider and SAML single sign-on for corporate SaaS applications and core services.
  • Automated provisioning and revocation, with access terminated within twenty-four (24) business hours of role change or departure.
  • User access reviews — quarterly for systems of high criticality; bi-annually to annually for other systems — to verify least-privilege alignment.
  • Privileged access requires asset-owner approval and strong authentication, with the four-eyes principle applied to highly sensitive actions.

3.4 Configuration and change management

  • All infrastructure and application changes undergo a documented change-management process, peer review and testing before deployment to production.
  • Development, testing and production environments are logically and physically isolated.
  • Vulnerability management: critical vulnerabilities remediated within seventy-two (72) hours; other vulnerabilities remediated within defined severity-based service levels.

3.5 System and network protection

  • Secure VPC architecture and firewalls preventing unauthorised lateral movement.
  • Web Application Firewall and Distributed Denial of Service (DDoS) protection at the production edge.
  • 24/7 security monitoring and centralised logging, with automated alerting on anomalous behaviour.
  • Security, application and infrastructure logs centrally collected, retained securely for at least one (1) year, and protected against tampering.
  • Industry-standard hardening baselines applied to all systems.
  • Cloud infrastructure capacity continuously monitored and dynamically scaled to ensure availability during demand spikes.

3.6 Asset and data protection

  • Customer Data encrypted at rest using AES-256 or equivalent.
  • All network traffic over external networks, including web traffic to the Application, encrypted in transit using TLS 1.2 or higher (TLS 1.3 preferred).
  • Full disk encryption mandated and enforced via mobile-device management on all Supplier workstations.
  • Endpoint detection and response (EDR) or anti-malware software centrally managed across all workstations.
  • Centrally managed mobile device management across all workstations, enforcing full disk encryption and configuration baselines.
  • Screen lock enforced after no more than 15 minutes of inactivity; clear-desk and clear-screen policy.
  • Information classified by sensitivity (Public / Internal / Restricted) and labelled in systems and documents.
  • Production customer data is strictly prohibited from being used in development or testing; synthetic, non-identifiable data is used for testing.
  • Data leakage prevention measures detect and prevent unauthorised extraction of sensitive data from the cloud environment.
  • Secure disposal of equipment and media using NIST-aligned wipe or destruction procedures.
  • Customer workspaces and personal data securely deleted from production databases on contract termination or verifiable customer request, in accordance with section 14 of the MSA.

3.7 Physical security

  • Production environment physical controls are inherited from AWS and validated annually through the Supplier's review of AWS compliance reports (ISO/IEC 27001 and SOC 2 Type I or II).
  • Entry to Supplier offices restricted and monitored via electronic access-control systems.
  • Remote workers are required by policy to protect equipment and information from unauthorised viewing or theft.

3.8 System development and operations

  • Mandatory secure-engineering principles documented and applied across all development, aligned with the OWASP Top 10.
  • Software composition analysis integrated into the CI/CD pipeline to detect known vulnerabilities in third-party dependencies.
  • Application security testing — including both manual and automated testing — completed before production deployment.
  • Annual third-party penetration testing of the Application and external network.
  • Continuous bug-bounty programme.

3.9 Incident response

  • Formal Incident Response Plan aligned with NIST SP 800-61 covering identification, containment, eradication and recovery.
  • Clear, accessible reporting mechanism for employees to report security weaknesses immediately.
  • Root-cause analysis and lessons-learned process for Severity-1 and Severity-2 incidents.
  • Personal data breach notification in accordance with section 6 of the DPA.

3.10 Vendor and third-party management

  • Security risk assessment of all critical third-party vendors before onboarding.
  • Information-security requirements (security obligations, confidentiality, incident notification, audit cooperation) formally addressed in contractual agreements with all suppliers who access, process or manage Customer Data.
  • Critical sub-processors subject to periodic security reviews including assessment of certifications, review of security incidents and evaluation of contractual compliance.
  • ICT supply-chain security risk management, including communication of security requirements to suppliers of ICT products and services.
04

Business continuity and disaster recovery

4.1

High availability. The core application architecture uses redundant components deployed across multiple independent availability zones to avoid single points of failure.

4.2

Backups. Automated, encrypted backups of the production database and configurations are performed regularly and stored in a separate geographical region from the production servers. Backups are retained for a minimum of seven (7) days in accordance with section 5.3 of the MSA.

4.3

Recovery objectives. The Supplier maintains a Recovery Point Objective (RPO) and a Recovery Time Objective (RTO) consistent with the high-availability multi-zone architecture described above and with enterprise-grade SaaS expectations. The Supplier shall make its then-current target RPO and RTO available to the Customer on written request, subject to the confidentiality obligations of the Agreement, and shall notify the Customer of any material change in those targets that would materially diminish the protection provided to the Customer.

4.4

Testing. The Supplier conducts disaster recovery and incident response simulations on at least an annual basis, and a formal backup restoration testing schedule is maintained with test restorations performed and validated to confirm data integrity and alignment with the RPO/RTO targets.

4.5

Customer cooperation. The Customer shall reasonably cooperate with the Supplier during business-continuity events, including in respect of communications, prioritisation and any temporary operational workarounds.

05

Artificial intelligence within the Service

This section 5 sets out the Supplier's durable commitments in respect of artificial intelligence within the Application. These commitments are designed to remain stable as the Supplier's AI capabilities evolve. The current list of AI capabilities available within the Application, including the underlying model provider for each capability and the in-product description, is published on the Supplier's Trust Center at https://trust.howspace.com (the "Trust Center AI Page"). The Trust Center AI Page is an exhaustive list of the AI capabilities offered by the Supplier; the AI capabilities actually available to the Customer depend on the Customer's subscription and on the sub-processors that the Customer has not objected to under section 3.3 of the DPA. The Supplier may update the Trust Center AI Page from time to time, subject to the commitments set out in this section 5 and to the sub-processor onboarding process in section 3 of the DPA.

5.1

Howspace's role under the EU AI Act. The Supplier acts as a "provider" of the AI capabilities offered within the Application within the meaning of Regulation (EU) 2024/1689 (the "EU AI Act"): those capabilities are downstream AI systems built into the Howspace platform and placed on the market under the Supplier's own brand. The Supplier is concurrently a "deployer" of the underlying general-purpose AI model that it obtains, as a service, from its AI sub-processor. The Supplier does not develop, train or fine-tune that underlying model. If the Supplier's role under the EU AI Act in respect of any AI capability changes (for example, if the Supplier begins to fine-tune a model or otherwise materially modifies its intended purpose in a way that changes the Supplier's role or the risk classification of the capability), the Supplier shall update this section 5 in accordance with section 15.2 of the MSA.

5.2

Risk classification — durable constraint. Any AI capability made available by the Supplier within the Application is, and shall remain, a low-risk AI use case under the EU AI Act. The Supplier shall not introduce any AI capability that:

  • constitutes a practice prohibited under Article 5 of the EU AI Act (including, without limitation, social scoring, criminality prediction based on profiling, emotion recognition in the workplace or in education, biometric categorisation inferring sensitive attributes, untargeted scraping of facial images, or real-time remote biometric identification in publicly accessible spaces for law enforcement); or
  • would be classified as a high-risk AI system under Annex III of the EU AI Act (including, without limitation, AI systems used for employment, worker management, access to essential services, credit scoring, education and vocational training assessment, or law enforcement),

without the Customer's prior written consent and the corresponding amendment of this section 5 in accordance with section 15.2 of the MSA. The Supplier has explicitly excluded the foregoing practices from its product roadmap.

5.3

No training on Customer Data. The Supplier shall not use Customer Data to train any Howspace, Supplier-controlled or third-party foundation model, large language model or other artificial intelligence model. This commitment applies to the Supplier and to each of its sub-processors used to provide AI capabilities, and corresponds to section 7.2 of the MSA. The Supplier shall not introduce, and shall not permit any sub-processor to introduce, any AI capability whose operation requires the use of Customer Data for model training.

5.4

AI sub-processors. Each AI capability within the Application is provided through one or more sub-processors listed in Schedule B of the DPA. The introduction of a new AI sub-processor (whether to provide an existing capability or to support a new capability) is subject to the sub-processor onboarding process in section 3.2 of the DPA, including the Customer's right to object on justified data-protection grounds under section 3.3 of the DPA. The Customer acknowledges that the Trust Center AI Page may be updated more frequently than Schedule B; in the event of any inconsistency, Schedule B (as updated under section 3.2 of the DPA) controls for the purposes of identifying the Supplier's sub-processors.

5.5

Transparency (Article 50 EU AI Act). Users are informed when they are interacting with AI capabilities. AI-generated content is distinguishable and appropriately explained in context. Documentation describing the purpose, functionality and limitations of each AI capability is published on the Trust Center AI Page.

5.6

Customer control. The Customer's administrators may disable AI capabilities for the Customer's tenant, or for specific workspaces or user groups, using the controls made available within the Application. Disabling an AI capability does not reduce the Service Fees and does not relieve the Customer of its commitments under the Agreement.

5.7

Trust Center AI Page. The Trust Center AI Page is an informational resource. The binding commitments of the Supplier in respect of artificial intelligence are those set out in this section 5 and in section 7 of the MSA. The Supplier shall maintain the Trust Center AI Page in a manner that accurately reflects the AI capabilities available within the Application from time to time.

5.8

Scope — Marketplace third parties excluded. The commitments in this section 5 apply only to AI capabilities provided by the Supplier as part of the Service. They do not extend to artificial intelligence functionality provided by third parties through the Howspace Marketplace ("Third-Party Offerings"). Where the Customer activates a Third-Party Offering that uses artificial intelligence, that functionality is provided to the Customer directly by the relevant third party under a separate agreement, and is governed by that third party's own AI commitments, data handling and EU AI Act compliance. The Supplier makes no representations about Third-Party Offerings in respect of artificial intelligence beyond those set out in the Howspace Marketplace Terms of Service.

06

Updates to this annex

The Supplier may update this Trust & Security Annex from time to time to reflect the evolution of the HCF and operational practices, subject to section 15.2 of the MSA. The Supplier shall not, by way of such updates, materially diminish the security, confidentiality or data-protection commitments to the Customer without the Customer's prior written consent.