Enterprise Terms

Parties and background

These IDZ Enterprise Terms, comprising this Master Services Agreement and its schedules (the "Enterprise Terms"), apply between: • IDZ LTD, incorporated in England and Wales under company number 10737703, with registered office at 128 City Road, London, EC1V 2NX ("IDZ"); and • the customer whose legal name and details appear in the Commercial Schedule signed by both parties ("Customer"). IDZ provides the Enterprise Services ordered by Customer. The Agreement takes effect through the signed Commercial Schedule and the specific Enterprise Terms version identified there, rather than through publication of these Terms alone.

1. Agreement structure and definitions

• 1.1 This Agreement consists of the Commercial Schedule signed by both parties and the exact Enterprise Terms version identified in it, including this Master Services Agreement, Schedule 1 (Service Description), Schedule 2 (Service Level Agreement or "SLA"), Schedule 3 (Data Processing Addendum or "DPA"), and DPA Annexes A-C. Customer-specific processing particulars and the initial subprocessor register expressly identified in the Commercial Schedule form part of the relevant DPA annex.
• 1.2 The DPA prevails for data-protection matters. A signed Special Term may expressly amend a specified DPA clause, but cannot reduce mandatory legal protection or override an applicable mandatory transfer instrument. For other matters, the order of precedence is: expressly identified Special Terms; the Commercial Schedule; the SLA for service-level matters; and the remainder of the Enterprise Terms. The public Privacy Policy is an information notice and does not override the Agreement or DPA.
• 1.3 "Affiliate" means an entity that directly or indirectly controls, is controlled by, or is under common control with a party.
• 1.4 "Authorised User" means a named individual whom Customer permits to access the Services, including Owners, Admins, Members, standalone Billing Admins and standalone Compliance/Auditors. Each Authorised User consumes one Seat unless the Commercial Schedule expressly states otherwise.
• 1.5 "Boost" means MetaCortex processing performed using a remote model, either on IDZ-approved remote computing infrastructure and a remote model. Boost may include Web-Assisted Queries where enabled.
• 1.6 "Business Day" means a day other than a Saturday, Sunday or public holiday in England.
• 1.7 "Commercial Schedule" means an order form or commercial schedule signed by both parties under this Agreement.
• 1.8 "Confidential Information" means non-public information disclosed by or on behalf of a party that is marked confidential or should reasonably be understood to be confidential, including Customer Data, security information, pricing, product roadmaps and trade secrets.
• 1.9 "Customer Data" means all files, chats, messages, prompts, notes, artefacts, outputs, indexes, memories, receipts, configuration and other content submitted to, stored in, generated through or processed by the Services for Customer.
• 1.10 "Customer Personal Data" means Personal Data processed by IDZ on behalf of Customer in connection with the Services, as described in the DPA.
• 1.11 "Documentation" means the operational user, administrator and technical product documentation made available for the Enterprise Services. Supplier due-diligence evidence and operational assurance packs are not contractual service specifications unless expressly incorporated as described in clause 1.25.
• 1.12 "Enterprise Workspace" means the Customer-controlled environment provisioned under a Commercial Schedule.
• 1.13 "Fees" means the fees and charges stated in the Commercial Schedule.
• 1.14 "IDZ Boost Pool" means the pooled allowance of successful IDZ-hosted Boost requests specified in the Commercial Schedule.
• 1.15 "Owner" means an Authorised User with the highest Enterprise administrative permissions, including authority to manage Owners, billing, policies, users, receipts, audit logs and Enterprise settings.
• 1.16 "Private Mode" means MetaCortex processing performed locally on a supported device using a downloaded local model.
• 1.17 "Recovery Credential" means a customer-controlled recovery account, key or kit created through the Services to support recovery of Owner access. IDZ does not retain the private recovery secret.
• 1.18 "Seat" means one licensed named Authorised User account, irrespective of how many roles are assigned to that user.
• 1.19 "Security Incident" means a confirmed breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Customer Personal Data processed by IDZ, excluding unsuccessful attempts that do not compromise security.
• 1.20 "Services" means the Enterprise services ordered under a Commercial Schedule, which may include ZCloud, ZChat, MetaCortex, the Admin Console, receipts, audit logs, support and related functionality.
• 1.21 "Subprocessor" means a third party appointed by IDZ to process Customer Personal Data on behalf of Customer.
• 1.22 "Web-Assisted Query" means a MetaCortex request that retrieves current public web content through an approved search or retrieval provider.
• 1.23 "Z.ID" means the privacy-preserving identifier used to access an IDZ account.
• 1.24 "Agreed Version" means the Enterprise Terms version identified by title, version identifier, publication date and version-specific URL or archived attachment reference in the signed Commercial Schedule.
• 1.25 Security, operational resilience, data-protection and supplier-risk/exit packs are supporting due-diligence material. They do not independently amend the Agreement. An identified extract or schedule becomes contractual only if the Commercial Schedule expressly incorporates its title, version, date and relevant provisions. This does not affect the binding status of DPA annexes or IDZ's responsibility for the accuracy of its statements.

2. Orders and provision of Services

• 2.1 No Services are ordered until both parties sign a Commercial Schedule. That signature constitutes acceptance of the Agreed Version, including the SLA and DPA, without separate signatures on the Enterprise Terms or their schedules. Both parties must have access to a downloadable or attached copy before signature. Mere browsing of the website does not constitute the Customer's acceptance.
• 2.2 IDZ will provide the Services during the applicable Order Term in accordance with this Agreement, the Commercial Schedule, the Documentation and applicable law.
• 2.3 IDZ may use Affiliates and subcontractors to provide the Services, subject to the confidentiality, security and data-protection obligations in this Agreement and the DPA.
• 2.4 IDZ may improve or modify the Services from time to time. IDZ will not materially reduce the core functionality purchased by Customer during the current Order Term, except where required for security, legal or third-party dependency reasons. IDZ will give reasonable notice of a material adverse change where practicable.
• 2.5 Preview, beta, pilot or experimental features are provided for evaluation, may change or be withdrawn, and are excluded from service levels unless the Commercial Schedule states otherwise.
• 2.6 The availability of features, models, supported file formats and device functionality may vary by operating system, device capability, region and Customer policy.

3. Enterprise workspace, roles and Authorised Users

• 3.1 IDZ will provision the Enterprise Workspace and invite the initial Owner identified in the Commercial Schedule. Customer is responsible for ensuring that each invitation is sent to an authorised person.
• 3.2 Customer must maintain at least one active Owner. The last Owner cannot be removed, demoted or suspended through self-service controls.
• 3.3 The primary roles are Owner, Admin and Member. Billing Admin and Compliance/Auditor permissions may be added to an Admin or Member, or assigned as standalone roles. An Owner already has full Enterprise permissions and does not require secondary role labels.
• 3.4 A standalone Billing Admin or Compliance/Auditor consumes one Seat. Standalone roles have access only to the relevant Admin Console functions and do not have ZCloud, ZChat or MetaCortex workspace access unless they also hold a primary role.
• 3.5 Customer is responsible for role assignments, invitations, suspensions, reactivations and removals performed by its Owners and Admins. IDZ is entitled to rely on instructions issued through authorised administrative accounts.
• 3.6 Suspension of an individual Authorised User under Customer's user-management controls is reversible and blocks new sign-ins and new synchronisation, revokes active server sessions where supported, and preserves the account, roles, Seat, files and chat history. Reactivation requires the user to authenticate again. Suspension does not erase data already stored on a device. Enterprise-wide non-payment suspension is a separate restriction governed by clauses 12.4–12.9, including the limited sign-in and billing access described there.
• 3.7 Authorised Users must not share account credentials. Customer must promptly remove or suspend access when an Authorised User no longer requires it or may pose a security risk.
• 3.8 Customer may authorise contractors as Authorised Users and remains responsible for their compliance with this Agreement.
• 3.9 All named users who can sign in to IDZ or the Admin Console count toward Seat allocation.

4. Customer responsibilities

• 4.1 Customer will:
• use the Services only for lawful business purposes and in accordance with this Agreement and the Documentation;
• obtain all rights, permissions, notices and lawful bases required for Customer Data and Customer instructions;
• maintain accurate administrative, billing and security contact information;
• secure its devices, networks, credentials, Z.IDs, Master Keys and Recovery Credentials;
• configure roles, policies, retention, sharing, model access and other controls appropriate to its risks;
• review MetaCortex outputs before relying on them or using them for legal, financial, regulatory, employment, medical or other material decisions;
• ensure that its use of the Services complies with professional duties, secrecy obligations, sector rules and Customer policies; and
• cooperate reasonably with IDZ in diagnosing security, support and service issues.
• 4.2 Customer must not, and must not permit any person to:
• use the Services to violate law, third-party rights or professional obligations;
• upload malware, conduct unauthorised security testing, disrupt the Services or attempt to gain access beyond authorised permissions;
• circumvent encryption, Seat limits, model entitlements, quotas, safety controls or billing mechanisms;
• reverse engineer or derive source code except to the limited extent that applicable law prohibits restriction;
• use the Services to build or train a competing product through systematic extraction, scraping or benchmarking of non-public behaviour; or
• submit data or instructions that Customer is not authorised to process.
• 4.3 Customer remains responsible for its business decisions, professional work product and regulatory obligations. The Services support, but do not replace, qualified human judgement.

5. Security, encryption, keys and recovery

• 5.1 IDZ is designed around client-side encryption and zero-knowledge principles. Customer Data may be stored and transmitted through IDZ systems as ciphertext, and IDZ does not hold the private keys required to decrypt protected Customer Data.
• 5.2 Customer is responsible for safeguarding authentication and encryption material. IDZ cannot recover a lost personal Master Key or private seed where no valid recovery route exists.
• 5.3 Customer may configure customer-controlled Recovery Credentials where that feature is included. Each Recovery Credential is generated locally, its private recovery material is exported once for secure Customer custody, and IDZ retains no recoverable copy of that private material.
• 5.4 A Recovery Credential is a Customer power, not an IDZ break-glass power. IDZ may verify an authorised recovery request and initiate the recovery workflow, but recovery of Owner access requires a valid Customer-held Recovery Credential or an existing authorised Owner.
• 5.5 Customer must store Recovery Credentials in secure, enterprise-controlled locations. If all Owner credentials and all valid Recovery Credentials are lost, the existing encrypted workspace may be permanently unrecoverable. IDZ may provision a new workspace but cannot recreate missing encryption secrets or restore inaccessible encrypted content.
• 5.6 A Recovery Credential associated with an Owner will be revoked when that Owner is removed or demoted. IDZ may require a replacement credential before allowing revocation of the last active recovery route.
• 5.7 IDZ will maintain appropriate technical and organisational measures as described in Annex B of the DPA. Customer acknowledges that no system can be guaranteed completely secure or continuously available.
• 5.8 IDZ may conduct vulnerability scanning, penetration testing, code review and independent security assessments. Customer must not perform or commission testing of the Services without IDZ's prior written consent and an agreed testing plan.

6. MetaCortex and artificial-intelligence features

• 6.1 MetaCortex may search and process supported Customer Data, provide cited answers, summarise, compare, extract, redact, create artefacts, use web assistance and perform other actions selected by an Authorised User or permitted by Customer policy.
• 6.2 Private Mode runs on supported devices using a downloaded local model. Device requirements, local model availability, performance and supported tasks may vary. Private Mode is not covered by the hosted-service availability calculation while operating locally.
• 6.3 Boost uses remote infrastructure and an approved remote model. Sanitisation is mandatory for IDZ's default third-party Boost route and is enabled by default for Customer-hosted endpoints. For sanitised requests, the Service extracts relevant context from files, chats or other protected Customer Data, replaces detected personal or sensitive details with placeholders, presents the applicable sanitised preview and obtains user approval under the enabled consent settings, including per-thread approval where available. The limited Customer-hosted endpoint exception in clause 7.4 applies only where expressly enabled by an Owner or Admin. Sanitisation reduces disclosure risk but does not guarantee that all personal or confidential information has been removed; Customer must ensure appropriate user review and lawful instructions.
• 6.4 Customer may configure Boost consent, web access, model tiers and other AI policies. Customer is responsible for determining whether those settings are appropriate for its use cases and professional or regulatory obligations.
• 6.5 A Web-Assisted Query may transmit a sanitised query to an approved search provider. The receipt should record that web assistance was used. Customer may disable Web-Assisted Queries for the Enterprise Workspace.
• 6.6 Receipts record available provenance information such as mode, model, sources, actions and approved data sharing. A receipt demonstrates recorded process and integrity; it does not certify that an AI output is factually or legally correct.
• 6.7 AI outputs may contain errors, omissions, outdated information, incomplete citations or non-unique content. Customer must independently verify material outputs and retain appropriate professional review.
• 6.8 IDZ will not use Customer Data, including files, chats, prompts or outputs, to train a general-purpose IDZ model or authorise its use to train third-party foundation models. For IDZ-procured inference, IDZ will require the applicable provider arrangements to prohibit use of Customer Data for foundation-model training. This restriction does not prohibit task-specific inference, encrypted indexing or user-controlled memory needed to deliver the Services.
• 6.9 Model labels such as Fast, Balanced and Most Capable are product tiers rather than guarantees of result quality. IDZ may change the underlying model within a tier where the replacement provides materially comparable or improved capability, security and availability.
• 6.10 Internal conversation compaction or summarisation used solely to maintain context does not count as a separate user-initiated Boost run unless the Commercial Schedule states otherwise.
• 6.11 Readable prompts, source content, web queries and model responses approved for remote processing are handled transiently to complete the requested task. IDZ will not retain them in readable form in its backend after the task completes, or record them in service logs, traces, crash reports or telemetry. Saved results, indexes, memories and receipts remain under customer-held encryption where storage or synchronisation is provided. Limited information deliberately submitted separately for support or diagnostics is handled only for that purpose, as described in the Privacy Policy; it does not authorise automatic capture of service payloads. External-provider handling is governed by DPA clause 3.3. These restrictions apply equally to authorised full-context Customer-hosted endpoint requests; enabling that setting does not permit readable payload retention by IDZ.

7. Customer-hosted AI endpoint

• 7.1 If ordered, Customer may route designated Boost requests through a Customer-hosted or Customer-approved endpoint. The supported endpoint contract, authentication methods, limits and policies are stated in the Documentation or Commercial Schedule.
• 7.2 Customer is responsible for the endpoint, underlying provider and model, credentials, capacity, performance, availability, security, licensing, data protection and regulatory compliance. IDZ is not responsible for the endpoint's acts, omissions or outputs.
• 7.3 IDZ will protect endpoint credentials using server-side secrets management and will not return an existing secret to the user interface. Customer must rotate credentials when compromised and promptly update IDZ.
• 7.4 Sanitisation and Customer-hosted endpoints. Sanitisation is enabled by default. Only sanitised, approved request data is sent to a Customer-hosted endpoint unless an Owner or Admin expressly enables "Send full context to customer-hosted endpoint", where the feature is implemented and included in the ordered Services. The following conditions apply:
• (a) Before activation, the Owner or Admin must be shown a clear warning that the selected request content, including any personal or confidential details within it, will be sent without sanitisation to the configured Customer-hosted endpoint.
• (b) IDZ will record each change to this setting in the Enterprise audit log. Where the app version supports it, the receipt for each affected request will record that full context was sent and identify the destination endpoint. Neither record, nor any IDZ service log, will contain the readable request payload.
• (c) "Full context" means only the content authorised and selected for the particular request, not unrestricted access to the Enterprise Workspace. Existing source-access permissions and user-approval settings continue to apply.
• (d) This setting applies only to the configured Customer-hosted endpoint. Sanitisation remains mandatory for IDZ's default third-party Boost route. Unsanitised content must not be automatically rerouted to that route. Any separately permitted fallback must first apply sanitisation and the applicable approval controls.
• (e) The Owner's or Admin's recorded selection is a documented Customer instruction under DPA clause 2.1, within the scope of this Agreement; a separate contract amendment is not required for each setting change. It does not override a stricter restriction in the signed Commercial Schedule, the authorised processing scope or applicable data-protection requirements.
• 7.5 Customer-hosted endpoint usage is metered separately and does not consume the IDZ Boost Pool unless the Commercial Schedule states otherwise. Any monthly ceiling on Customer-hosted endpoint requests is stated in the Commercial Schedule. Only successful requests count towards it.
• 7.6 IDZ may enforce technical safeguards including request-size limits, timeouts, retries, rate limits and concurrency controls. If usage exceeds a ceiling stated in the Commercial Schedule, IDZ will notify the Customer. IDZ will not silently fall back to IDZ Boost unless Customer has expressly enabled and approved that fallback. Any permitted fallback to IDZ's default third-party Boost route is subject to clause 7.4(d); full-context authorisation does not carry over to that route.
• 7.7 Endpoint failures may be retried for transient errors and may cause the endpoint to be marked Degraded or Unavailable. Such failures are excluded from the IDZ-hosted availability calculation.

8. Customer Data and privacy

• 8.1 As between the parties, Customer owns all right, title and interest in Customer Data. Customer grants IDZ a limited, non-exclusive licence to host, transmit, process and otherwise use Customer Data only as necessary to provide, secure and support the Services and comply with law.
• 8.2 The DPA in Schedule 3 applies where IDZ processes Customer Personal Data on behalf of Customer. Each party remains responsible for its own compliance with applicable data-protection law.
• 8.3 IDZ acts as an independent controller for limited business-contact, contracting, billing, security and legal-compliance information for which it determines the purposes and means of processing. The public Privacy Policy at https://idz.com/privacy/ describes that processing; it is a transparency notice, not a substitute for, or unilateral amendment to, the DPA.
• 8.4 IDZ does not sell Customer Data or use protected Customer Data for advertising or behavioural profiling.
• 8.5 IDZ may create aggregate or statistical information that does not identify Customer, any Authorised User or any data subject and cannot reasonably be used to reconstruct Customer Data. IDZ may use such information to operate, secure and improve the Services.
• 8.6 IDZ does not retain readable email or telephone aliases or upload or retain user address books. Device, operating-system and connection information used for core-service compatibility or routing is processed transiently and is not retained by IDZ or associated with a Z.ID, except where deliberately supplied in a support or diagnostic report. IDZ may retain the minimum opaque account, entitlement, quota, workspace and administrative audit records needed to provide the Services, and business, billing or support information voluntarily supplied for those purposes. These records are not used for advertising or behavioural profiling. Synthetic checks and aggregate service-health measurements may support availability and security monitoring without retaining customer payloads or creating user-device profiles.

9. Confidentiality

• 9.1 The receiving party will: (a) use the disclosing party's Confidential Information only to perform or exercise rights under this Agreement; (b) protect it using at least reasonable care; and (c) disclose it only to personnel, professional advisers and subcontractors who need to know it and are bound by confidentiality obligations.
• 9.2 Confidential Information excludes information that the receiving party can demonstrate: (a) is public through no breach; (b) was lawfully known without restriction; (c) was received lawfully from a third party without duty; or (d) was independently developed without use of the disclosing party's information.
• 9.3 A receiving party may disclose Confidential Information where legally required, provided it gives advance notice where lawful and reasonable assistance to seek protective treatment.
• 9.4 Neither party may use the other party's name, marks or relationship in publicity without prior written consent, except that IDZ may identify Customer internally and to its professional advisers and subcontractors as needed to perform the Agreement.

10. Intellectual property

• 10.1 IDZ and its licensors retain all rights in the Services, Apps, models, software, Documentation, designs, methods, know-how, improvements and related intellectual property, excluding Customer Data.
• 10.2 Subject to payment of Fees and compliance with this Agreement, IDZ grants Customer a non-exclusive, non-transferable right during the Order Term to permit Authorised Users to access and use the Services for Customer's internal business purposes.
• 10.3 Customer owns Customer-specific reports, notes and artefacts generated from Customer Data to the extent permitted by law and third-party model terms. Customer acknowledges that AI outputs may not be unique and similar output may be generated for others.
• 10.4 If Customer provides suggestions or feedback, Customer grants IDZ a perpetual, worldwide, royalty-free right to use it without identifying Customer or disclosing Customer Confidential Information.
• 10.5 Third-party and open-source components remain subject to their respective licence terms.

11. Fees, invoicing and taxes

• 11.1 Customer will pay the Fees set out in the Commercial Schedule. Minimum commitments are payable whether or not all Seats or included allowances are used.
• 11.2 Unless otherwise stated, base committed Fees are invoiced in advance and usage, extra Seats and other overages are invoiced in arrears. The Commercial Schedule sets the billing frequency and true-up period.
• 11.3 All Fees are exclusive of VAT and other applicable taxes. Customer will pay applicable taxes except taxes based on IDZ's net income.
• 11.4 Invoices are due within the payment period stated in the Commercial Schedule. A purchase-order requirement does not relieve Customer of payment obligations or extend an agreed due date.
• 11.5 Customer must raise a good-faith invoice dispute within 15 days after invoice date, identifying the disputed amount and reasons. Customer will pay undisputed amounts on time, and the parties will work promptly to resolve the dispute.
• 11.6 IDZ may charge interest and recovery costs on overdue undisputed amounts at the rate stated in the Commercial Schedule or, if none is stated, the rate permitted under the Late Payment of Commercial Debts (Interest) Act 1998.
• 11.7 Except where expressly stated, Fees are non-cancellable and non-refundable. Service Credits and any statutory rights are unaffected.

12. Suspension

• 12.1 IDZ may suspend affected access where reasonably necessary to: (a) prevent or address a security risk; (b) respond to unlawful use; (c) comply with law or a binding direction; (d) protect the Services or other customers; or (e) address overdue undisputed Fees after reasonable notice, subject to the non-payment timetable and access protections in clauses 12.4-12.9 and 16.3.
• 12.2 Where practicable, IDZ will give prior notice, limit the suspension to the affected Services or accounts, and restore access promptly after the issue is resolved.
• 12.3 Suspension does not relieve Customer from Fees accruing during the suspension where the suspension arises from Customer's breach or non-payment.
• 12.4 Renewal payment grace. Unless expressly agreed otherwise in the Commercial Schedule, existing Enterprise Core Services remain active from the renewal invoice due date through Day 14 overdue. IDZ will notify the Owner and Billing Admin promptly, repeat reminders during that period and identify the payment deadline and suspension date. IDZ may block Seat-allocation increases and purchases of additional paid allowances during the grace period. If the undisputed renewal amount remains unpaid on Day 15 overdue, IDZ will suspend the Enterprise Workspace under clauses 12.6-12.8. Days are calendar days counted from the agreed renewal invoice due date, not the invoice issue date or number of collection attempts. Good-faith disputes remain subject to clause 11.5.
• 12.5 Initial payment. The Commercial Schedule must state the initial invoice payment period and any agreed payment-method-specific activation requirements. During that period, non-receipt of payment alone does not block the agreed onboarding or Core Services, subject to existing technical, security and production-acceptance gates. Owners and Admins may perform configuration, member-record and invitation actions within their existing permissions; recovery actions do not gain additional permissions under this clause. If the initial invoice remains unpaid when that period expires, onboarding and member activation are paused, Core Services are blocked, and only Owner/Billing Admin billing and support access remains available. No additional Seats or paid usage may be added. The initial-payment pause does not receive a second renewal grace period. Cancellation is governed by clause 16.3.
• 12.6 Limited access during renewal suspension. Owners and Billing Admins retain access to Billing & invoices, payment details and invoice downloads, together with billing/support assistance. An Admin without Billing Admin permissions retains sign-in access only to the suspension status and support contact. Members and other users retain sign-in access only to the suspension notice. These exceptions do not grant new roles or billing permissions. Limited post-termination return/export access is governed by clause 16.7 and DPA clauses 9.2-9.4.
• 12.7 Suspended Core Services. Non-payment suspension blocks Enterprise ZCloud access, uploads, downloads and synchronisation; ZChat sending and receiving; MetaCortex Private, Boost, web-assisted and Company AI requests; Customer-hosted endpoint requests; public/private links and shared-file access; Notes and artefacts; member invitations, role and Seat changes; policy/configuration changes; and new overage usage. These restrictions apply to the Enterprise Workspace, including requests using Customer-provided AI infrastructure, not to unrelated personal accounts.
• 12.8 Preservation. A failed payment or suspension does not itself delete Customer Data, cancel existing roles or convert the Enterprise Workspace into individual Free accounts. Encrypted workspace data, accounts, roles, Seat records, receipts, audit logs, policies, endpoint configuration and recovery configuration are preserved subject to existing lawful retention and deletion instructions. Previously downloaded local content cannot necessarily be erased remotely, but suspension does not permit continued organisational syncing or service requests. Termination, data return and subsequent deletion follow clause 16 and DPA clause 9.
• 12.9 Restoring access. Before termination, IDZ will promptly lift the non-payment restriction once the required payment is verified and no other suspension ground remains. Existing roles, permissions and configuration are retained; any separate user or security suspension remains in effect. After termination, restoration must be agreed with IDZ while the data remains available and is not guaranteed after deletion. Payment status and entitlements must be verified; changing payment details or returning from a billing portal alone is not confirmation of payment.

13. Warranties and disclaimers

• 13.1 Each party warrants that it has authority to enter into this Agreement.
• 13.2 IDZ warrants that during the Order Term: (a) the hosted Services will materially conform to the Documentation; (b) IDZ will provide the Services with reasonable skill and care; and (c) IDZ will not knowingly introduce malicious code into the Services.
• 13.3 Customer's exclusive remedy for breach of clause 13.2 is for IDZ to use reasonable efforts to correct the non-conformity or, if IDZ cannot do so within a reasonable time, permit Customer to terminate the affected Service and receive a pro-rata refund of prepaid Fees for the unused terminated period.
• 13.4 Except as expressly stated and to the maximum extent permitted by law, the Services are provided "as is" and "as available". IDZ does not warrant uninterrupted or error-free operation, that every file format or task will be supported, that AI outputs will be accurate or complete, or that the Services will meet every regulatory requirement applicable to Customer.
• 13.5 IDZ is not a law firm, financial adviser, medical provider, auditor or regulated professional adviser. The Services do not provide professional advice.

14. Indemnities

• 14.1 IDZ will defend Customer against a third-party claim that Customer's authorised use of the Services infringes a UK patent, copyright or trade mark, and will pay damages and costs finally awarded or agreed in settlement, provided Customer promptly notifies IDZ, gives IDZ control of the defence and reasonably cooperates.
• 14.2 IDZ has no obligation for a claim arising from Customer Data, Customer instructions, Customer-hosted endpoints, combination with items not supplied by IDZ, use outside the Documentation, continued use after notice, or modifications not made by IDZ.
• 14.3 If an infringement claim is likely, IDZ may procure continued use, modify or replace the affected Service, or terminate it and refund prepaid Fees for the unused period. This clause states Customer's exclusive remedy for third-party IP infringement by the Services.
• 14.4 Customer will defend IDZ against third-party claims arising from Customer Data, Customer's unlawful use of the Services, Customer-hosted endpoints, or Customer's breach of clause 4, and will pay damages and costs finally awarded or agreed in settlement, subject to equivalent notice, control and cooperation requirements.

15. Liability

• 15.1 Nothing in this Agreement excludes or limits liability for death or personal injury caused by negligence, fraud or fraudulent misrepresentation, deliberate default, or any liability that cannot lawfully be excluded or limited.
• 15.2 Neither party is liable for indirect or consequential loss, loss of profit, revenue, anticipated savings, goodwill or business opportunity, or loss or corruption of data, except to the extent such loss constitutes direct costs of restoring Customer Data from available backups following IDZ's breach.
• 15.3 Subject to clauses 15.1 and 15.4, each party's aggregate liability arising out of or in connection with this Agreement in any rolling 12-month period will not exceed the Fees paid or payable under the affected Commercial Schedule during that period.
• 15.4 The aggregate liability of a party for breach of confidentiality, breach of the DPA, a Security Incident caused by its failure to comply with the agreed security measures, and its indemnity obligations under clause 14 will not exceed 200% of the Fees paid or payable under the affected Commercial Schedule during the relevant 12-month period.
• 15.5 Customer's obligation to pay Fees and each party's liability under clause 15.1 are not subject to the caps in clauses 15.3 or 15.4.
• 15.6 The limitations apply to all causes of action in aggregate and reflect the allocation of risk and Fees. Service Credits count toward, and do not increase, the applicable liability cap.

16. Term, termination and exit

• 16.1 The Agreement begins on the Order effective date specified in the signed Commercial Schedule or, if none is specified, the date of the last party's signature. It continues until all Commercial Schedules have expired or been terminated.
• 16.2 Each Commercial Schedule continues for its Initial Order Term and renews as stated in that schedule.
• 16.3 Either party may terminate this Agreement or an affected Commercial Schedule for material breach, other than the non-payment cases below, if the breach is not cured within 30 days after written notice. A breach incapable of cure, other than non-payment, may be terminated immediately. For an unpaid undisputed renewal invoice, IDZ may terminate the affected Commercial Schedule on or after Day 30 overdue following final written notice under clause 18.1. If an initial invoice remains unpaid after 30 calendar days of the initial-invoice timetable agreed in the Commercial Schedule, IDZ may cancel the Order Form following written notice. Neither event is automatic deletion: the 30-day post-termination return/export period in clause 16.7 and the non-payment closure procedure in DPA clause 9.4 apply.
• 16.4 Either party may terminate immediately if the other becomes insolvent, ceases business or is subject to an analogous insolvency event, except where prohibited by law.
• 16.5 Customer may terminate an affected Commercial Schedule where a regulator with jurisdiction over Customer issues a binding direction requiring termination, provided the parties first use reasonable efforts to address the concern. Customer will pay Fees accrued to termination and any non-cancellable third-party commitments identified in the Commercial Schedule.
• 16.6 On termination: (a) ordinary service access ends, but limited access required for the export period in clause 16.7 remains available through supported tools, subject to lawful security restrictions; (b) Customer must pay amounts due; (c) each party returns or destroys Confidential Information as required; and (d) the DPA governs return and deletion of Customer Personal Data.
• 16.7 Unless the Commercial Schedule states otherwise, Customer will have 30 days after termination to export available Customer Data through supported tools. IDZ may provide additional transition assistance at its then-current professional-services rates. After termination or cancellation for non-payment under clause 16.3, IDZ will keep the limited return/export access needed for that 30-day period and will act on Customer's choice of return or deletion under the DPA. This access does not restore the other Services. The 30-day period starts on the date the termination or cancellation takes effect.
• 16.8 Because IDZ does not hold Customer's private decryption keys, Customer is responsible for maintaining the keys and devices required to decrypt any export. IDZ cannot provide plaintext exports of content it cannot decrypt.

17. Compliance, assurance and regulatory cooperation

• 17.1 Each party will comply with applicable anti-bribery, anti-corruption, sanctions, export-control and modern-slavery laws in connection with this Agreement.
• 17.2 Customer is responsible for determining whether its use of the Services constitutes outsourcing or a material third-party arrangement and for obtaining any required approvals or notifications. IDZ will provide reasonable information and cooperation to support Customer's supplier due diligence and regulatory obligations.
• 17.3 On request and subject to confidentiality, IDZ will make available then-current security materials reasonably relevant to the Services, which may include independent assessment summaries, certifications, policies, architecture summaries, subprocessor information, business-continuity information and completed security questionnaires.
• 17.4 Customer may audit IDZ only as provided in the DPA or where a regulator with authority over Customer requires additional access. Audits must be proportionate, coordinated, confidential, non-disruptive and avoid access to other customers' information or IDZ source code unless expressly agreed.
• 17.5 IDZ does not warrant that the Services alone make Customer compliant with any law, professional rule or regulatory regime.

18. General

• 18.1 Notices. Legal notices must be in writing and delivered by email and, for termination or material breach notices, by recorded delivery or recognised courier to the addresses stated in the Commercial Schedule. Notices are deemed received on the next Business Day after email transmission unless a delivery failure is received.
• 18.2 Assignment. Neither party may assign this Agreement without the other's consent, not to be unreasonably withheld, except to an Affiliate or in connection with a merger, reorganisation or sale of substantially all relevant assets, provided the assignee is able to perform the obligations. Customer may not assign to a direct competitor of IDZ without consent.
• 18.3 Force majeure. Neither party is liable for delay caused by events beyond its reasonable control, excluding payment obligations. The affected party will mitigate and provide notice. If a material force-majeure event continues for more than 60 days, either party may terminate the affected Service.
• 18.4 No partnership. The parties are independent contractors. Nothing creates a partnership, agency, fiduciary relationship or employment relationship.
• 18.5 Third-party rights. Except for permitted assignees and as expressly stated, no person may enforce this Agreement under the Contracts (Rights of Third Parties) Act 1999.
• 18.6 Waiver and severability. A waiver must be in writing. If a provision is unenforceable, it will be modified to the minimum extent necessary and the remainder continues.
• 18.7 Entire agreement. This Agreement constitutes the entire agreement on its subject and supersedes prior proposals and discussions. Each party acknowledges that it has not relied on any statement not set out in the Agreement, without limiting liability for fraud.
• 18.8 Amendments and online version control. The Agreed Version remains binding for the applicable Commercial Schedule, including a renewal unless the parties expressly agree otherwise in writing. Publishing a new website version does not change an existing Agreement. Substantive amendments require a signed variation or a signed Commercial Schedule expressly identifying the replacement version. Operational contacts and changes expressly permitted under the Agreement, including authorised subprocessor changes under the DPA, may be updated through their agreed process. IDZ will retain and provide the Agreed Version on request.
• 18.9 Counterparts and electronic signature. The Agreement may be signed electronically and in counterparts, each of which is an original and together form one instrument.
• 18.10 Governing law and jurisdiction. The Agreement and non-contractual obligations are governed by the laws of England and Wales. The courts of England and Wales have exclusive jurisdiction, after senior representatives first attempt in good faith to resolve a dispute for at least 20 Business Days.

Schedule 1 – Service Description

1. Platform components

• ZCloud: End-to-end encrypted file storage, synchronisation, indexing of supported formats, search, controlled sharing and workspace file access.
• ZChat: Encrypted one-to-one and group messaging, private file sharing and conversation-based collaboration.
• MetaCortex: AI-assisted search, cited answers, summarisation, comparison, extraction, redaction, artefact generation, Private Mode, Boost and optional web assistance.
• Admin Console: Management of roles, Seats, AI policies, sharing policy, receipts, billing overview, pooled usage, audit logs and configured Enterprise features.
• Receipts and auditability: Signed or cryptographic records of available AI provenance, together with administrative audit events. Bulk receipt export is available only where specified in the Commercial Schedule.
• Customer-hosted endpoint: Optional routing of designated remote AI requests to a Customer-configured endpoint, subject to clause 7 and the Commercial Schedule.

2. Roles

• Owner: Core permissions: Full Enterprise control, including Owners, Admins, billing, policies, users, receipts, audit logs, settings and recovery. At least one Owner is required. Workspace access: Yes.
• Admin: Core permissions: Members, roles, Seats, AI policies, sharing, receipts, usage and audit logs. No ownership transfer or billing access by default. Workspace access: Yes.
• Member: Core permissions: Normal use of ZCloud, ZChat, MetaCortex and features allowed by policy. Workspace access: Yes.
• Billing Admin: Core permissions: Billing portal, invoices, payment details, tax/VAT details and billing contacts. May be standalone or added to Admin/Member. Workspace access: Yes.
• Compliance/Auditor: Core permissions: Read-only access to receipts, audit logs, usage and permitted exports. May be standalone or added to Admin/Member. Workspace access: Yes.

3. Enterprise usage and policy model

• Storage, IDZ Boost and other allowances are generally pooled at Enterprise level unless the Commercial Schedule states otherwise.
• Regular Members do not see exact pooled Boost usage or overage figures; they see whether Boost is available. Exact pool information is restricted to authorised Admin Console roles.
• The backend enforces the Boost tiers available under the Customer's contract and policy. The underlying model name is recorded in receipts where available.
• Customer policies may control default AI mode, Boost, web assistance, model tiers, sharing, memory, receipts and related features.
• Retention controls are enforceable only to the extent implemented by the relevant client and backend components. IDZ will not represent a reporting-only setting as completed deletion.
• One completed user task counts as one Boost request regardless of the selected model tier. A clarification requested before the task is completed remains part of the same request; a new follow-up after a completed answer is a new request. Requests that fail without a usable response due to an IDZ or provider error do not count.

4. Exclusions and dependencies

• Customer devices, internet access, app stores, Customer-hosted endpoints and third-party services outside IDZ's control are excluded from hosted availability commitments.
• Private Mode performance depends on local hardware, downloaded models and device resources.
• Unsupported, corrupted, image-only or legacy file formats may be stored but not fully indexed or processed.
• OCR, transcription and AI extraction may contain errors and require review.

Schedule 2 – Service Level Agreement

1. Scope

• SLA 1.1 This SLA applies only to production IDZ-hosted Enterprise Services identified as "Covered Services" in the Commercial Schedule. It excludes Private Mode, Customer devices, Customer-hosted endpoints, third-party payment portals, app stores, web search providers and beta features.

2. Availability commitment

• SLA 2.1 IDZ will use commercially reasonable efforts to achieve 99.9% Monthly Availability for the Covered Services, unless a different target is stated in the Commercial Schedule.
• SLA 2.2 "Monthly Availability" means 100% minus the percentage of total minutes in the calendar month during which the Covered Services are unavailable to substantially all affected users, measured by IDZ's service monitoring.
• SLA 2.3 Unavailable minutes exclude:
• Scheduled Maintenance notified at least five Business Days in advance and not exceeding four hours in a calendar month;
• Emergency Maintenance reasonably necessary to protect security or service integrity;
• Customer systems, configurations, devices, networks, credentials, Customer-hosted endpoints or acts and omissions;
• third-party services outside IDZ's reasonable control, including app stores, telecommunications, internet routing and web search providers;
• force-majeure events;
• suspension permitted under the Agreement; and
• preview, beta or pilot features.

3. Service Credits

• 99.9% or above: No credit
• At least 99.0% but below 99.9%: 5% of the monthly recurring Fee for the affected Covered Service
• At least 95.0% but below 99.0%: 10% of the monthly recurring Fee for the affected Covered Service
• Below 95.0%: 20% of the monthly recurring Fee for the affected Covered Service
• SLA 3.1 Customer must request a Service Credit within 30 days after the affected month, with reasonable supporting details. Credits apply to a future invoice, are not cash refunds, and are capped at 20% of the monthly recurring Fee for the affected Service for that month.
• SLA 3.2 Service Credits are Customer's sole monetary remedy for failure to meet Monthly Availability, without limiting rights for other breaches, Security Incidents or termination rights expressly provided in the Agreement.

4. Support and incident priorities

• P1 – Critical: Example: Production service unavailable to most users; confirmed severe security incident; widespread inability to access encrypted workspace. Initial response target: 1 hour, 24×7 for nominated contacts. Target handling: Continuous reasonable efforts until service restored or workaround provided.
• P2 – High: Example: Material feature unavailable to many users with no reasonable workaround. Initial response target: 4 Support Hours. Target handling: Prioritised investigation and regular updates.
• P3 – Normal: Example: Degraded or incorrect non-critical behaviour with workaround. Initial response target: 1 Business Day. Target handling: Handled during normal support operations.
• P4 – Low: Example: Question, cosmetic issue or feature request. Initial response target: 2 Business Days. Target handling: Planned or advised as appropriate.
• SLA 4.1 Support Hours are 09:00-17:30 UK time on Business Days unless the Commercial Schedule specifies enhanced support.
• SLA 4.2 Response targets are objectives, not resolution guarantees. Customer must provide reasonably requested information and access needed to investigate.

5. Security incidents

• SLA 5.1 IDZ will notify Customer without undue delay and, where reasonably practicable, within 24 hours after becoming aware of a Personal Data Breach affecting Customer Personal Data. The target does not permit IDZ to delay a notification required by DPA 8.1. Initial information may be incomplete and will be updated as investigation progresses; IDZ need not wait for a completed investigation.
• SLA 5.2 Notifications will use the nominated security contacts and include available information about the nature, likely consequences, affected categories, mitigation and contact point.

6. Continuity, recovery and maintenance

• SLA 6.1 IDZ maintains business-continuity and disaster-recovery arrangements appropriate to the Services. The target RTO and RPO, where contractually committed, are set out in the Commercial Schedule.
• SLA 6.2 RTO and RPO apply to IDZ-hosted control-plane and server-side service state. They do not constitute a promise that IDZ can decrypt or recreate Customer Content where Customer-held keys are unavailable.
• SLA 6.3 IDZ will test relevant continuity and incident-response procedures periodically and may provide summary evidence under confidentiality on request.

Schedule 3 – Data Processing Addendum

1. Scope and roles

• DPA 1.1 This DPA applies to IDZ's processing of Customer Personal Data on behalf of Customer in connection with the Services.
• DPA 1.2 Customer is the controller and IDZ is the processor, except where a party acts as an independent controller for its own business-contact, billing, security, fraud-prevention or legal-compliance processing.
• DPA 1.3 Terms such as controller, processor, Personal Data, processing, data subject, Personal Data Breach and supervisory authority have the meanings in applicable Data Protection Law.
• DPA 1.4 "Data Protection Law" means the UK GDPR, the Data Protection Act 2018, the Privacy and Electronic Communications Regulations 2003, and other applicable data-protection law, in each case as amended or replaced.

2. Instructions and compliance

• DPA 2.1 IDZ will process Customer Personal Data only on Customer's documented instructions, including instructions contained in the Agreement, Commercial Schedule, Customer's configuration and Authorised User actions, unless UK law requires otherwise. Where legally permitted, IDZ will inform Customer before processing required by law. An Owner's or Admin's logged selection under MSA clause 7.4 is such an instruction only for the configured endpoint and permitted request scope, and does not displace required user approvals.
• DPA 2.2 IDZ will promptly inform Customer if, in IDZ's reasonable opinion, an instruction infringes Data Protection Law. IDZ may suspend the affected instruction while the parties address the concern.
• DPA 2.3 Customer is responsible for the lawfulness, fairness, transparency and accuracy of Customer Personal Data and instructions, including required notices, consents and lawful bases.

3. Confidentiality and personnel

• DPA 3.1 IDZ will ensure that personnel authorised to process Customer Personal Data are subject to confidentiality obligations and receive appropriate security and privacy training.
• DPA 3.2 Protected files, chats, indexes, memories, saved results and receipts remain subject to customer-held encryption; IDZ does not possess the private keys needed to read them in storage. Approved sanitised content may be processed transiently to complete Boost or web-assisted requests. Where an Owner or Admin enables full context under MSA clause 7.4, the authorised selected request content may also be handled transiently, without sanitisation, by IDZ's gateway and its infrastructure providers solely to route the request to the configured Customer-hosted endpoint and return the response. This is not a direct encrypted channel bypassing IDZ where its gateway is used. IDZ's backend, logging and telemetry treatment must comply with MSA clauses 6.11 and 8.6. No standing support access to readable encrypted workspace content or private Customer keys is granted by this DPA.
• DPA 3.3 IDZ's own non-retention commitment is distinct from processing by an approved external provider. Any provider-specific security or abuse-prevention handling, including retention, must be verified, documented and disclosed with the relevant processing particulars before the route is authorised. IDZ will use the approved retention and no-training configuration and comply with the DPA's instruction, subprocessor and transfer provisions. A provider feature does not authorise undisclosed payload logging by IDZ or a silent relaxation of Customer policy. A provider directly procured by Customer remains subject to clause 5.5 of this DPA. For a Customer-procured endpoint, Customer determines and documents that provider's processing locations, retention and contractual safeguards; IDZ remains responsible for the processing performed by its own gateway and appointed Subprocessors.

4. Security

• DPA 4.1 IDZ will implement and maintain the technical and organisational measures in Annex B, taking into account the state of the art, implementation costs, nature, scope, context and purposes of processing, and risks to data subjects.
• DPA 4.2 Customer acknowledges that Customer controls key security measures including user roles, devices, local credentials, encryption keys, Recovery Credentials, sharing settings, model policies and approval of Boost or web processing.
• DPA 4.3 IDZ may update security measures where the update does not materially reduce the overall protection of Customer Personal Data.

5. Subprocessors

• DPA 5.1 Customer gives general written authorisation for IDZ to use the actual Subprocessors recorded in the initial Annex C register identified in the signed Commercial Schedule. Changes follow clauses 5.2-5.4. A reference to a model name or technology provider alone does not establish that the provider receives Customer Personal Data or acts as an IDZ Subprocessor.
• DPA 5.2 IDZ will notify Customer at least 15 days before appointing a new Subprocessor that will process Customer Personal Data, except an urgent appointment required to address a security or continuity risk, in which case notice will be given as soon as reasonably practicable.
• DPA 5.3 Customer may object on reasonable data-protection grounds within the notice period. The parties will work in good faith on a commercially reasonable solution. If no solution is available, either party may terminate the affected processing feature; Customer remains liable for Services not affected and for non-cancellable commitments.
• DPA 5.4 IDZ will impose data-protection obligations on each Subprocessor that provide an equivalent level of protection relevant to the processing and remains responsible for its Subprocessors' performance of those obligations.
• DPA 5.5 A Customer-hosted endpoint or other provider selected and contracted directly by Customer is not an IDZ Subprocessor. Customer is responsible for that provider.

6. International transfers

• DPA 6.1 IDZ will not make a restricted transfer of Customer Personal Data outside the United Kingdom unless an applicable adequacy regulation, exception or appropriate safeguard is in place.
• DPA 6.2 Where required, the relevant parties will complete and put in place the ICO International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses before the restricted transfer, together with the required transfer assessment and supplementary measures. A generic reference in this Agreement is not, by itself, a completed transfer instrument.
• DPA 6.3 IDZ will provide reasonable information about processing locations and transfer mechanisms on request.
• DPA 6.4 The primary location for IDZ-hosted encrypted Customer Content is Ireland. Locations used for replicas, backups, control-plane processing, AI inference and support must be identified separately in the Commercial Schedule and approved Annex C. Storage in Ireland does not mean that every processing activity takes place there. Any change remains subject to Customer instructions, the Agreement and the applicable DPA authorisation and transfer provisions.

7. Data-subject rights and regulatory assistance

• DPA 7.1 Taking into account the nature of processing, IDZ will provide reasonable assistance to Customer in responding to data-subject requests. Because IDZ cannot read protected Customer Data, Customer is responsible for using available user-side tools and keys to identify, access, export, correct or delete such data.
• DPA 7.2 If IDZ receives a request relating to Customer Personal Data, IDZ will redirect it to Customer where reasonably identifiable and will not respond substantively except on Customer's instructions or where legally required.
• DPA 7.3 IDZ will provide reasonable assistance with Customer's data-protection impact assessments, prior consultations and regulatory inquiries relating to the Services, taking into account the nature of processing. IDZ may charge reasonable fees for material assistance beyond standard documentation, unless required due to IDZ's breach.

8. Personal Data Breaches

• DPA 8.1 IDZ will notify Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data and will provide available information reasonably required for Customer's notification and assessment obligations.
• DPA 8.2 IDZ will investigate, mitigate and remediate within its responsibility, preserve relevant evidence, and provide updates. Notification is not an admission of fault or liability.
• DPA 8.3 Customer is responsible for incidents caused by Customer-controlled devices, credentials, keys, configurations, users or Customer-hosted endpoints, without limiting IDZ's duty to cooperate where the Services are involved.

9. Return and deletion

• DPA 9.1 During the Order Term, Customer may delete or export Customer Data using supported features, subject to encryption and key availability and the non-payment workspace-access restrictions in MSA clause 12. Those restrictions do not remove the post-termination return/export arrangements in clauses 9.2-9.4.
• DPA 9.2 At the end of the processing, and at Customer's choice, IDZ will delete or return Customer Personal Data, unless UK law requires retention. Return may be by encrypted self-service export because IDZ cannot produce plaintext that it cannot decrypt.
• DPA 9.3 Unless otherwise stated in the Commercial Schedule, Customer has 30 days after termination to export available data. IDZ will then place remaining Customer Data beyond active use and delete it from active systems within 30 days and from encrypted backup cycles within 90 days, except where retention is legally required or technically impossible without disproportionate effect on immutable backups. Retained backup data remains protected and is not restored except for disaster recovery.
• DPA 9.4 Non-payment closure. Suspension alone does not trigger deletion. Following termination or cancellation for non-payment under MSA clause 16.3, IDZ will preserve the workspace for the 30-day post-termination return/export period, unless Customer gives a valid earlier deletion instruction or law requires otherwise. If, by the end of that period, the Customer has neither restored the service nor completed an export, IDZ will, following final notice to the Customer, delete the live encrypted workspace. A completed export is handled under Customer's return/deletion instructions in clause 9.2 and does not itself restore the subscription. At final closure, invalidate workspace sharing links and access credentials and revoke IDZ-held endpoint access; Customer remains responsible for credentials at its own endpoint. Retain only billing, contract and audit records required by law, with documented exceptions. Put backup copies beyond use and remove them through the documented backup lifecycle, subject to the backup deadline and lawful exceptions in clause 9.3.

10. Information, audit and records

• DPA 10.1 IDZ will provide information reasonably necessary to demonstrate compliance with this DPA, including available certifications, independent assessment summaries, policies and completed questionnaires.
• DPA 10.2 Customer may conduct one audit in any 12-month period, and additional audits following a material Personal Data Breach or regulator request, subject to at least 30 days' notice where practicable, confidentiality, reasonable scope, use of an independent qualified auditor, and avoidance of disruption or access to other customers' data.
• DPA 10.3 Customer bears audit costs unless the audit identifies a material breach by IDZ, in which case IDZ will reimburse reasonable direct audit costs. IDZ may satisfy an audit request through recent independent reports where those reports reasonably address the requested control.
• DPA 10.4 IDZ will maintain records of processing required by applicable law.

11. Liability and precedence

• DPA 11.1 The liability provisions of the Agreement apply to this DPA. Nothing relieves either party of direct statutory responsibilities under Data Protection Law.
• DPA 11.2 If this DPA conflicts with the remainder of the Agreement on data-protection matters, this DPA prevails.

Annex A – Details of Processing

• Subject matter: Provision, administration, support, security and use of the IDZ Enterprise Services, including encrypted storage, messaging, AI processing, receipts, audit logs and related controls.
• Duration: For the Order Term and the deletion/return period described in the DPA.
• Nature and purpose: Hosting and synchronising ciphertext; routing messages and files; administering workspace roles and policies; processing approved sanitised content for IDZ Boost or web assistance; routing authorised selected full-context requests only to the configured Customer-hosted endpoint under MSA clause 7.4; producing and storing encrypted indexes, memories, outputs and receipts; support, security and incident handling.
• Categories of data subjects: Customer personnel, contractors, clients, prospective clients, counterparties, suppliers and other individuals whose data Customer submits or processes.
• Types of Personal Data: Encrypted files and communications; names, contact details, identifiers, professional and financial information, document content, correspondence, prompts and outputs, technical and audit metadata, and any other data selected by Customer. Special-category or criminal-offence data may be included only where Customer has a lawful basis and appropriate controls.
• Processing operations: Collection from Customer/user devices, encryption, transmission, storage as ciphertext, retrieval, synchronisation, indexing, search, AI inference on approved sanitised context, transient routing of authorised selected full-context requests to the configured Customer-hosted endpoint under MSA clause 7.4, web query processing, access-control administration, deletion and export.
• Customer instructions: The Agreement, Commercial Schedule, Customer's settings and policies, and actions of Authorised Users acting within assigned permissions.

Annex B – Technical and Organisational Measures

• Encryption and key control: Client-side encryption for protected content; encryption in transit; server-side encryption for operational systems; Customer-held private keys for protected content; no standing IDZ access to plaintext encrypted workspace content.
• Identity and access: Role-based access, named accounts, least privilege, administrative controls, session revocation, strong authentication measures appropriate to the component, and restricted production access.
• Secure development: Code review, dependency and vulnerability management, separation of environments, change control, security testing and remediation processes.
• Infrastructure security: Cloud security controls, network segmentation, hardened configurations, secrets management, monitoring and protective controls appropriate to hosted components.
• Logging and auditability: Restricted, integrity-protected administrative audit records and service-security records, limited to approved metadata. No readable service prompts, source content, web queries, model responses, private encryption keys or Recovery Credentials in logs, traces, crash reports or telemetry. Synthetic/aggregate health measurements and limited audit metadata support monitoring without core-user IP histories or device-to-Z.ID profiles. Deliberately submitted support diagnostics follow MSA 6.11 and 8.6.
• Incident response: Documented detection, escalation, containment, investigation, notification and remediation processes, with nominated contacts and post-incident review.
• Resilience: Redundancy appropriate to hosted components, backup and recovery procedures, continuity planning, periodic testing and capacity monitoring.
• Personnel and governance: Confidentiality obligations, role-appropriate security training, joiner/mover/leaver controls and documented security responsibilities.
• AI processing controls: Separate Private and Boost modes; sanitisation ON by default and mandatory for IDZ's default third-party Boost route; configured user approvals and source permissions. Full context only to the configured Customer-hosted endpoint under MSA 7.4, an Owner or Admin enables it and is shown a clear warning; each setting change is audit-logged and, where the app version supports it, each affected receipt records full-context use and destination. No automatic unsanitised fallback. Transient gateway processing and no readable backend payload retention under MSA 6.11. No general-purpose/foundation-model training under MSA 6.8. Provider-specific handling verified and disclosed under DPA 3.3.
• Data minimisation and privacy: Core accounts do not require conventional personal identifiers. No retained readable aliases or address books; core-service device/connection information remains transient and is not retained or associated with Z.ID except for deliberately submitted diagnostics. Minimum opaque service and Enterprise audit records, and volunteered business/billing/support information, remain purpose-limited under MSA 8.6. No sale or advertising/profiling use of Customer Data.
• Recovery: Customer-controlled Recovery Credentials where enabled; IDZ retains no private recovery secret; recovery actions are verified and audit-logged.
• Assurance: Independent security review and testing, security questionnaires and certification roadmap as applicable and described in the Commercial Schedule.

Annex C – Approved Subprocessors

The initial Customer-specific subprocessor register must be completed and identified by title, version and date in the signed Commercial Schedule. It forms this Annex C and may be supplied as the approved register extract from the Operational Data-Protection Pack.

• Amazon Web Services: Purpose: Cloud hosting, encrypted storage, database, compute, networking, security services, push-notification relay (Amazon SNS), transactional email (Amazon SES), AWS Lambda and Amazon Bedrock. Data involved: Ciphertext, approved operational metadata, Enterprise workspace directory data (member names and email addresses), push-notification tokens, email recipient addresses and sanitised IDZ Boost and web-query content. Where AWS infrastructure hosts IDZ's gateway for an authorised full-context Customer-hosted request, it may transiently handle that selected payload for routing only; this is not permission to send unsanitised content to IDZ's default Bedrock/model route. Legal role / location: Subprocessor. Storage, database, compute and backups: Ireland (eu-west-1), with no replicas outside Ireland. Transactional email: Sweden (eu-north-1). AI inference: see the Amazon Bedrock rows.
• Anthropic model technology via Amazon Bedrock: Purpose: Foundation-model inference where an Anthropic model is selected. Data involved: Approved prompt/output processed by the configured inference service; has no access to prompts or outputs processed on Amazon Bedrock. Legal role / location: Not a Subprocessor (model technology only). Amazon Bedrock EU cross-region inference: Ireland, Germany, France, Sweden, Italy, Spain; no routing outside the EU.
• Amazon model technology via Amazon Bedrock: Purpose: Amazon Nova inference for Web-Assisted Query planning and answer synthesis. Data involved: Search query, fetched public web content and generated answer. Legal role / location: Amazon Bedrock EU cross-region inference: Ireland, Germany, France, Sweden.
• DuckDuckGo web search via DDGS, plus Amazon Bedrock Nova Pro using the EU inference profile, invoked from AWS Lambda in eu-west-1: Purpose: Web-assisted query retrieval when enabled. Data involved: Search query text is sent to DuckDuckGo. The query text and up to six fetched public web pages are then sent to Amazon Bedrock Nova Pro to generate the response. Legal role / location: Web-Assisted Queries are enabled by default and may be disabled by an Owner or Admin. Search queries are sent from AWS eu-west-1 to DuckDuckGo under DuckDuckGo's applicable privacy terms. The query and retrieved public content are processed through Amazon Bedrock Nova Pro using the EU inference profile. AWS acts as IDZ's subprocessor for the Lambda and Bedrock processing. No user name, contact details or Z.ID is attached to the search query.
• Sentry: Purpose: Error monitoring for backend services and apps. Data involved: Error stack traces without local variables, request bodies or default personal data; app crash device and operating-system data. Legal role / location: Subprocessor; EU data region.
• Apple APNs, Google FCM and Microsoft WNS (via Amazon SNS): Purpose: Push-notification delivery. Data involved: Device push token and notification text. Legal role / location: Amazon Web Services acts as IDZ's subprocessor for Amazon SNS, operated from AWS eu-west-1. Apple, Google and Microsoft receive the applicable device token or registration identifier and notification payload as platform push-notification providers under their respective terms. IDZ minimises notification content and uses localisation keys or non-sensitive text wherever practicable.

Acceptance through the Commercial Schedule

The parties sign only the Commercial Schedule / Order Form. Its acceptance clause incorporates the Agreed Version of these Enterprise Terms, the SLA, the DPA and the identified DPA annexes. A separate signature on this document is not required.