Data Protection, Security & Compliance Policy

This policy states how Truce.ai protects data. It is written to answer, in one place, the questions asked in a security review, a data protection impact assessment, a tender's technical compliance sheet and a regulator's enquiry.

It covers the Truce platform and every module and API under it, the infrastructure it runs on, the AI models it uses, our development, support and operations processes, our personnel, and the sub-processors we engage.

Throughout our website and documentation, Truce and Truce.ai are used interchangeably and refer to the same platform.

This policy describes practice. It does not replace a contract. Where a Data Processing Agreement, Master Services Agreement, Order Form or government contract states a specific commitment, that instrument governs. Where this policy describes a capability as planned rather than current, the Safe Harbour Policy applies.

Read this policy with the Privacy Policy, which covers the lawful basis and purpose of processing, and the Terms & Conditions, which set out ownership and liability.

Truce.ai is a trademark of Virtuos Digital Limited, operated through its Futuristry Division. Futuristry is a Strategic Business Unit (SBU) at Virtuos, formed under the Virtuos Transformation Economy initiative, which exists to build AI-native products rather than to retrofit intelligence onto legacy systems.

Truce is an Accord Lifecycle Intelligence (ALI) platform, governing the whole life of an accord — intent, drafting, negotiation, execution, obligations, performance, variation, renewal and closure — with machine intelligence applied throughout.

ALI differs from traditional Contract Lifecycle Management, with overlap in authoring, clause libraries, approvals, repositories, e-signature and renewals. Where CLM manages documents, ALI reasons about live accords and the obligations they create. That difference shapes this policy: a CLM security model concerns storage, access and transport, while an ALI security model must also govern what happens when text is reasoned over — which model sees it, in which region, under what retention terms, with what audit trail.

We chose the .ai extension deliberately. Accord Lifecycle Intelligence is built on frontier models and Truce is AI-first and AI-born. Clause 14 governs the model layer, and we consider it the most important section of this document for any assessor evaluating an AI-native platform.

Your data is yours. We are a custodian, not an owner. We acquire no rights in Customer Data beyond what is needed to run the service for you.

We do not train on your data. Customer Data is never used to train, fine-tune or improve any foundation or frontier model, ours or a third party's. Our model provider contracts prohibit it.

Residency is a commitment, not a preference. Your data stays in the region you choose. We strictly observe local data residency requirements and the laws that create them.

Least data, least access, least time. We collect what is needed, grant the narrowest access that works, and hold it for the shortest period the purpose and the law allow.

Protection is designed in. Data protection by design and by default is a requirement at architecture review, not a control added before an audit.

Transparency over comfort. We tell customers what happened, including when it is uncomfortable, and we tell them early rather than completely.

The exit is as good as the entrance. A customer who wants to leave gets its data out in a usable form. Retention is never a retention strategy.

Accountability for data protection and security sits with the leadership of the Futuristry SBU and is exercised through defined roles.

We maintain a risk register covering security, privacy, AI and third-party risk, reviewed by the committee, with owners and remediation dates for each entry.

We maintain records of processing activity, a data inventory and data flow documentation, and we support customers conducting Data Protection Impact Assessments by providing the technical information they need.

Exceptions to this policy require documented approval, a compensating control, an expiry date and a review at expiry. Standing exceptions are not permitted.

Government and PSU deployments may carry an additional classification defined by the customer's own scheme. Where a customer's classification requires handling beyond the table above, it is recorded in the contract and implemented as a tenant-specific control.

Customer Data is treated as Restricted by default. We do not downgrade a classification without the customer's written instruction.

Truce runs exclusively on tier-one public cloud infrastructure: Amazon Web Services, Microsoft Azure and Google Cloud. We operate no data centres of our own and no colocation facilities.

This is a deliberate architectural decision. It gives every customer — including a state department with a modest budget — the physical security, redundancy, network capacity, regional breadth and independently audited control environment of the world's largest infrastructure operators. We inherit and rely on their certifications for the infrastructure layer, and we are responsible for everything above it.

The hosting provider for a given tenant is determined by the customer's region, regulatory requirement and, where a customer has a cloud preference or an existing enterprise agreement, that preference. The provider is recorded in the Order Form.

Platform architecture uses managed services, infrastructure as code, immutable deployment, private networking with no direct public exposure of data stores, segmented environments, and deployment across multiple availability zones within the chosen region.

Cloud provider certifications and audit reports — including ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2 and regional attestations — are available directly from those providers and cover the infrastructure layer only. Our own assurance position is at clause 21.

We monitor cloud configuration continuously against a hardened baseline, with automated detection and correction of drift, and we do not permit manual configuration changes to production outside the change process.

We strictly follow local data residency requirements and the laws that create them. Each tenant is provisioned in a nominated region recorded in the Order Form, and Customer Data stays there.

Residency covers the whole data estate, not just the primary database: primary storage, object storage of documents and attachments, search and vector indexes, derived insight, caches, queues, backups, disaster-recovery copies, audit logs and — wherever the model is regionally available — AI inference.

Where a statute, sectoral regulator or tender requires stricter localisation than the table describes — an in-country sovereign region, a government community cloud, a specific empanelled provider, or in-country storage of logs — we implement it and record it contractually.

We do not move a tenant between regions without the customer's written instruction. Where a migration is needed, it is planned, tested, and executed with the customer's approval and a documented rollback.

On request we will confirm in writing the specific region, provider and services in use for a customer's tenant, for inclusion in that customer's own compliance records.

Customer Data does not leave its region as a matter of routine operation. Where any cross-border element arises, it is limited, disclosed and safeguarded.

The circumstances in which access from outside the region may occur are: follow-the-sun engineering support on an escalated incident; 24×7 security monitoring; and, where a customer has enabled a capability available only outside its region, the operation of that capability. Each is disclosed in advance.

Where transfer or remote access occurs, we apply as appropriate: adequacy decisions; the European Commission's Standard Contractual Clauses; the UK International Data Transfer Addendum; a documented transfer impact assessment covering the destination country's legal regime and government access powers; and supplementary technical measures including encryption in transit and at rest, pseudonymisation where feasible, least-privilege time-bound access, session recording and full audit logging.

A customer may require region-locked operation. Where selected, support and monitoring are staffed from within the region, no access from outside is permitted, and the restriction is enforced technically and recorded contractually. This may reduce support coverage hours, which we state before the option is taken.

Onward transfer by a sub-processor is permitted only under terms at least as protective as those we owe the customer, and with the same safeguards.

Transfer mechanisms and summary transfer impact assessments are available to customers on written request at privacy@truce.ai.

Different customers carry different constraints. We support a range of deployment models, recorded in the Order Form, with the security characteristics of each stated below.

Deployment models outside multi-tenant SaaS carry different commercial terms, different service levels and, in some cases, different release cadence and AI feature availability. We state those differences before contracting rather than after.

Availability of a specific deployment model for a specific region or workload is confirmed at the time of contracting. Any model described as planned rather than current is governed by the Safe Harbour Policy.

In transit. All data in transit is encrypted using TLS 1.2 or above with strong cipher suites. Weak protocols and ciphers are disabled. HTTP Strict Transport Security is enforced. Internal service-to-service traffic is encrypted within the private network.

At rest. All data at rest is encrypted using AES-256 or an equivalent standard, covering databases, object storage, search and vector indexes, queues, caches, backups and disaster-recovery copies.

Key management. Keys are managed in the hosting cloud's managed key service, backed by hardware security modules. Keys are separated by environment and by tenant where the deployment model provides it, rotated on a defined schedule, and access to key material is restricted, logged and reviewed.

Customer-managed and customer-held keys. Dedicated and single-tenant deployments support customer-managed keys, allowing the customer to control rotation and to revoke access. Customer-held key arrangements, where revocation renders data unreadable to us, are available by agreement — with the operational consequences, including irrecoverability on key loss, stated in writing before adoption.

Field-level protection. Nominated fields can be encrypted at field level, redacted, tokenised or masked, so that particularly sensitive elements of an accord are protected even from an authorised viewer of the surrounding document.

Secrets, credentials and API keys are held in a managed secrets service, never in source code, configuration files, tickets or documentation. Automated secret scanning runs across repositories and blocks commits containing credentials.

Access follows least privilege. Personnel receive the narrowest permission set that allows them to do their work, granted by role rather than individually, and reviewed rather than assumed.

Multi-factor authentication is mandatory for all personnel access to production, administrative consoles, source control and cloud accounts. Shared accounts are prohibited; every action is attributable to a named individual.

Production access is just-in-time: elevated access is requested for a stated reason, approved by a second person, granted for a limited window, and revoked automatically on expiry. Standing production access is not granted.

Access to Customer Data by our personnel occurs only for a defined support or incident purpose. It is authorised, time-limited, logged in a tamper-evident trail, and reviewable by the customer. Where a customer enables customer-approved access, our personnel cannot enter the tenant without the customer granting approval for each occasion.

Access is reviewed at least quarterly, and immediately on role change, transfer or exit. Deprovisioning on exit is completed on the last working day.

For customer-side identity, the platform supports SAML and OIDC single sign-on, SCIM provisioning and deprovisioning, granular role-based access control, delegated administration, IP allow-listing, session timeout policy and device posture requirements where the customer's identity provider supplies them.

Break-glass access for emergencies uses separately controlled credentials, requires dual authorisation, generates an immediate alert, and triggers a mandatory post-use review.

Every customer's data is logically separated from every other customer's, with isolation enforced at multiple layers rather than relying on a single control.

Application layer: every data access path carries a mandatory tenant context; queries without it fail rather than defaulting to broad access. Authorisation is evaluated on every request, not only at session start.

Data layer: tenant identifiers are enforced at the storage layer, with row-level or schema-level separation depending on the deployment model, and dedicated stores in dedicated and single-tenant deployments.

Key layer: separate encryption keys per tenant where the deployment model provides them, so that a failure of logical separation does not yield readable data.

AI layer: inference context is assembled only from the requesting tenant's data. Retrieval indexes are tenant-scoped. Derived insight is written back only to the originating tenant. There is no cross-tenant pooling of content, embeddings or insight.

Isolation controls are covered by automated regression tests on every release and are within the scope of independent penetration testing.

Security requirements are defined at design. Features that process Customer Data or change an access path go through a threat modelling and architecture review before development starts.

All code is peer reviewed before merge. Direct commits to production branches are blocked. Every change is traceable to an author, a reviewer and a ticket.

Automated security testing runs in the pipeline: static application security testing, software composition analysis for known vulnerabilities in dependencies, container and image scanning, infrastructure-as-code scanning, and secret detection. Findings above defined severity thresholds block release.

Development, test, staging and production are fully segregated, with separate credentials, networks and keys. Production Customer Data is never copied into a non-production environment. Testing uses synthetic or fully anonymised data.

Changes to production follow a documented change management process with approval, testing evidence, deployment records and a rollback plan. Emergency changes follow an expedited path with mandatory retrospective review.

Engineers receive secure development training at induction and annually, covering the vulnerability classes relevant to our stack and to AI systems specifically, including prompt injection, insecure output handling and data leakage through model context.

Truce is AI-first and AI-born, built on frontier models. The controls in this clause exist because a conventional application security model does not address the model layer.

Customer Data is never used to train, fine-tune, re-train or otherwise improve any foundation or frontier model, ours or a third party's. Contracts with our model providers prohibit the use of submitted data for training or model improvement, and prohibit retention beyond what is needed to return a response, subject only to any contractually agreed and disclosed abuse-monitoring window. The sole exception is a bespoke model specifically ordered by a customer for its own exclusive use under a statement of work, which is never made available to any other customer.

Inference runs inside the customer's chosen region wherever the model is regionally available, preferentially through a model service running within the same cloud region as the tenant. Where a required capability is available only outside the region, we disclose it, obtain a decision before enabling it, and apply the safeguards at clause 8. AI features can be disabled individually or entirely at tenant level.

Only the minimum context needed for a task is submitted. The platform supports redaction and tokenisation of identified personal data before submission, and configurable exclusion of nominated fields, clause types or document classes from AI processing.

Models are selected against criteria covering accuracy on accord-specific tasks, safety behaviour, regional availability, data handling terms, latency and cost. New models and versions are evaluated against a maintained test suite before adoption, and evaluation results are retained.

Model versions in use are recorded. Where a model change materially affects a capability a customer relies on, clause 18 of the Terms & Conditions governs notice and remedies.

Accords are untrusted input. A document can contain text designed to manipulate a model. We apply input handling controls, instruction and content separation, output validation, constrained tool and action permissions, and monitoring for anomalous model behaviour. Injection defence is an explicit scope item in penetration testing.

Truce produces recommendations, extractions, classifications, scores and drafts. A person decides. Where an outcome affects an individual's rights, entitlements, employment, benefits, licences or access to a public service, meaningful human oversight is required, and customers must give affected individuals a route to human review. Clause 12 of the Terms & Conditions makes this a condition of use.

AI-assisted actions are logged: what was requested, which feature ran, when, for which user, and what was produced. The trail supports a customer's own audit, explanation and regulatory obligations.

Where the EU AI Act or a comparable regime applies, we act as provider and the customer as deployer. We supply technical documentation, logging, accuracy information and oversight capability that a deployer reasonably needs, and we state where responsibility sits between us. Classifying a use case and meeting the deployer obligations that follow is the customer's responsibility.

Application, infrastructure, database, network and security logs are centralised in a protected log platform with restricted access and integrity protection, so that logs cannot be altered or deleted by an account that could compromise the system they record.

Logged events include authentication and authorisation decisions, administrative actions, privileged access grants and use, configuration changes, data export and bulk read operations, permission changes, and AI-assisted actions.

Security monitoring operates continuously, with alerting on anomalous authentication, unusual data access volumes, privilege escalation, configuration drift, known indicators of compromise and unexpected outbound traffic. Alerts route to an on-call rota with defined response times.

Customers have access to their own tenant audit trail through the platform and API, covering user actions, administrative changes, access by our personnel, and AI-assisted actions.

Log retention is typically 12 months, extended where a contract, regulator or investigation requires it. Where CERT-In directions apply, logs are retained within India for the prescribed period, and systems are synchronised to the prescribed time source.

Logs are treated as Confidential or Restricted depending on content, and log data is subject to the same residency commitments as Customer Data.

Continuous vulnerability scanning runs across application, infrastructure, container images and dependencies. Cloud configuration is assessed continuously against a hardened baseline.

Independent penetration testing is conducted periodically by qualified third parties, covering the application, API, infrastructure, tenant isolation and the AI layer. Findings are tracked to closure and a summary report is available to customers under non-disclosure agreement.

Where a fix cannot meet the target, a compensating control is applied, the risk is recorded with an owner and a date, and the exception is reviewed by the security committee.

We maintain a responsible disclosure programme. Security researchers may report findings to security@truce.ai. We acknowledge within 3 business days, investigate, keep the reporter informed, and do not pursue legal action against good-faith research conducted within the published scope.

Customers may conduct their own penetration testing with prior written consent and an agreed rules-of-engagement document, as clause 7 of the Terms & Conditions provides.

We maintain a documented incident response plan covering detection, triage, severity classification, containment, eradication, recovery, notification, evidence preservation and post-incident review. It is tested at least annually, including a tabletop exercise involving engineering, security, legal and communications.

A defined on-call rota provides 24×7 response capability. Incidents are classified by severity, with response and escalation targets attached to each level.

Notification to a customer includes the nature of the incident, the categories and approximate volume of data and individuals affected, the likely consequences, the containment and remediation steps taken, and a named contact for follow-up.

We do not delay notification to complete an investigation. We tell customers what we know when we know it, and we update as the picture develops. An incomplete early notification is better than a complete late one.

Every significant incident is followed by a blameless post-incident review identifying root cause and corrective actions, with owners and dates. Corrective actions are tracked to closure and reviewed by the security committee.

Where a customer's own regulator requires direct notification, or where a public sector contract prescribes a reporting route, we follow that route in addition to the timelines above.

The platform is deployed across multiple availability zones within the chosen region, with automated failover for critical components, so that the loss of a single zone does not cause loss of service.

Backups are automated, encrypted, and stored within the tenant's region. Backup frequency, point-in-time recovery capability, and retention are set to meet the recovery objectives in the applicable service description.

Restoration is tested on a defined schedule. A backup that has not been restored is not a backup, and we treat successful restoration testing as the measure, not backup completion.

Recovery time and recovery point objectives are stated in the Service Level Agreement or service description applicable to a customer's deployment model, and differ between multi-tenant, dedicated and customer-subscription deployments.

Business continuity and disaster recovery plans cover infrastructure failure, regional disruption, supplier failure, ransomware and loss of key personnel. Plans are reviewed annually and exercised on a defined cadence.

Where a customer requires cross-region disaster recovery, the secondary region is chosen so that residency commitments are preserved, and the arrangement is recorded in the Order Form.

We engage a deliberately small set of sub-processors. Each is assessed before engagement against security posture, certifications, data handling terms, residency capability, financial stability and, for model providers, training and retention terms.

Every sub-processor is bound by a written contract imposing data protection obligations no less protective than those we owe our customers, including confidentiality, security measures, breach notification, audit cooperation, residency, restrictions on onward transfer and deletion on termination.

Sub-processors receive the minimum data needed for their function. We do not grant a vendor broader access for convenience.

The current sub-processor list, with entity, function, processing location and scope, is maintained at www.truce.ai and provided to customers on request. Customers may subscribe to change notifications.

We give advance notice of any addition or replacement of a sub-processor, with a reasonable window for a customer to object on genuine data protection grounds. Where a reasonable objection cannot be resolved, the customer may terminate the affected service without penalty for the unused portion of its prepaid term.

Sub-processors are reassessed periodically and on any material change to their service, ownership, security posture or the terms on which they handle data. We monitor for security incidents affecting our vendors and assess the impact on our customers.

Background verification is conducted on personnel with access to production systems or Customer Data, to the extent permitted by local law, covering identity, employment and education history, and criminal record where lawful.

All personnel sign confidentiality undertakings covering Customer Data and platform information, surviving the end of their engagement. Contractors are bound by equivalent terms.

Security and privacy training is mandatory at induction and annually, with role-specific training for engineering, support and personnel handling Customer Data. Training completion is tracked, and non-completion is escalated.

Access is granted on a documented approval, reviewed quarterly, and revoked on the last working day of an engagement. Asset return and account deactivation are part of a documented exit checklist.

Breach of this policy is a disciplinary matter and may result in termination and, where warranted, referral to authorities.

Endpoints. Company devices are managed, with full-disk encryption, endpoint detection and response, automatic patching, screen lock, and remote wipe capability. Access to production and Customer Data from unmanaged devices is prohibited. Remote and home working is subject to the same controls.

Physical security of the infrastructure is provided by AWS, Microsoft Azure and Google Cloud, and is covered by their independently audited control environments. Our own offices operate access control, visitor management, clear-desk practice and secure disposal of media, but hold no production Customer Data.

Our control environment is designed and operated against recognised frameworks, including ISO/IEC 27001 for information security management, ISO/IEC 27701 for privacy information management, ISO/IEC 27017 and 27018 for cloud and cloud privacy, SOC 2 Trust Services Criteria, the NIST Cybersecurity Framework and the Cloud Security Alliance Cloud Controls Matrix. Our AI governance is designed against ISO/IEC 42001 and the NIST AI Risk Management Framework.

The current status of each certification, attestation and empanelment, together with available audit reports, penetration test summaries, security questionnaire responses and completed CAIQ documentation, is provided to customers and qualified prospects under a non-disclosure agreement on request.

Certifications held by AWS, Microsoft Azure and Google Cloud cover the infrastructure layer and are available directly from those providers. Their certification is not ours, and we do not present it as ours.

The table below maps the principal regimes we operate under. It is not exhaustive, and a customer's own sectoral obligations may add to it.

Compliance is a shared outcome. We meet our obligations as a processor and as a platform provider; a customer's own obligations as controller, deployer or regulated entity remain with the customer. Clause 24 sets out the division.

A substantial part of our work is with governments, ministries, statutory bodies, regulators, municipal corporations and Public Sector Undertakings. Public sector accords — procurement, concessions, grants, licences, public–private partnership, land, welfare delivery, defence-adjacent supply — carry obligations that commercial contracts do not.

Where a tender or contract requires it, we support: hosting in a nominated in-country region, an empanelled provider or a government community cloud; segregated or single-tenant deployment; deployment inside the department's own cloud subscription or data centre; support delivered exclusively by in-country personnel; and no access from outside the country under any circumstance.

We support security clearance, police verification and background checks for named personnel to the extent lawful, and we will name the individuals who hold access to a department's tenant.

We support restricted administrative access with customer-approved break-glass procedures, extended and tamper-evident audit logging, retention schedules aligned to public records law and departmental record-retention rules, and reporting routes prescribed by the department or by CERT-In.

We cooperate with audit and inspection by the Comptroller and Auditor General, internal audit, vigilance functions and any regulator with jurisdiction, on the terms recorded in the contract or tender document.

Where an authority is subject to right-to-information or freedom-of-information law, we assist it in locating and producing records held in the platform, and we do not assert confidentiality over the authority's own records to obstruct a lawful disclosure obligation. We ask only that our genuinely proprietary technical and commercial information be handled under the exemptions the relevant statute provides.

Statements in a bid about capabilities, certifications, empanelments or residency options we do not yet hold are forward-looking and governed by the Safe Harbour Policy. We disclose gaps rather than obscure them, including where disclosure costs us the bid.

Security is divided across three parties. Knowing which obligations are yours is the difference between a secure deployment and a compliant-looking one.

The most common cause of a customer-side incident is not a platform weakness. It is a departed employee whose account was never deprovisioned, an over-broad role granted for convenience, or an integration authorised without review. We provide the tooling and the reporting to prevent all three; using them is the customer's responsibility.

We publish administrator guidance and a security configuration checklist, and we will review a customer's configuration against it on request as part of onboarding or an annual health check.

Customers are entitled to satisfy themselves that we do what this policy says. We support that through documentation first and on-site audit where a contract or regulator requires it.

Available on request, under a non-disclosure agreement: current certification and attestation status; third-party audit reports where we hold them; penetration test summary reports; completed security questionnaires including CAIQ; architecture and data flow documentation; the sub-processor list; our business continuity and incident response summaries; and confirmation of the region, provider and services in use for the customer's tenant.

Where a customer's regulator, or a public procurement contract, requires a direct audit right, we accommodate it on reasonable notice, during business hours, no more than once annually except following a material incident or where a regulator directs otherwise, subject to confidentiality and to the security of other customers not being compromised. Multi-customer audits may be satisfied through a pooled audit or an independent report where the contract permits.

We cooperate with audits conducted by supervisory authorities, sectoral regulators, the Comptroller and Auditor General and departmental vigilance functions, as the applicable contract provides.

We do not permit audit activity that would give one customer access to another customer's data, environment or configuration. Where an audit requirement cannot be met without doing so, we will offer an independent third-party audit as an alternative.

Where we act as processor, requests from individuals go to the customer as controller. We provide the tooling for a customer to locate, export, correct, restrict and delete personal data within its tenant without needing our involvement.

Where a request needs our assistance, we respond to the customer within 5 business days of a written request, and we provide reasonable assistance for the customer to meet its own statutory deadline.

Where an individual approaches us directly about data held in a customer's tenant, we do not act on the request ourselves. We route it to the customer, confirm to the individual that we have done so, and identify the controller where we may lawfully do so.

Where we act as controller — for website visitors, prospects, our own personnel and applicants — we handle requests directly under the Privacy Policy.

Requests are logged, tracked and closed with a record of the action taken, and the record is available to the customer for its own accountability documentation.

Customers control retention of their own data within the platform through configurable retention policies applied by record type, matter type or classification.

On expiry or termination, Customer Data remains available for export for 30 days, or longer where the Order Form or a public sector exit management obligation provides. Export delivers structured data with source documents and audit records in supported formats, and we will describe the export schema in advance so a migration can be planned.

After the export window, Customer Data is deleted from production within 30 days and from backups within a further 90 days as backup cycles expire. Deletion covers primary storage, object storage, search and vector indexes, caches and derived insight.

Where immediate deletion is not possible — data in an immutable backup, a write-once archive required by law, or under a litigation hold or regulatory preservation notice — the data is isolated, active processing stops, and deletion occurs when the constraint lifts. We tell the customer where this applies.

A certificate of deletion is provided on written request, identifying what was deleted and when.

Media disposal is handled by the cloud providers under their certified destruction processes. We do not hold Customer Data on physical media we control.

This policy is owned by the Head of Security and the Data Protection Officer, approved by the Futuristry executive sponsor, and reviewed at least annually.

It is reviewed out of cycle on: a material change to architecture, hosting or the model layer; a new or amended law or regulator direction; a significant incident; a material audit finding; or a change in sub-processors that affects data handling.

The version number and effective date at the head of this document identify the current edition. Previous versions are retained and provided to customers on request.

Material changes are notified to customers at least 30 days before taking effect, by email to account administrators and by publication at www.truce.ai. We will not materially reduce the security measures described here during a customer's subscription term.

Where this policy describes a capability as planned rather than current, the Safe Harbour Policy applies and the capability must not be relied on in a purchase decision.

Security correspondence is acknowledged within 3 business days. Assurance packages for procurement and security review are provided under a non-disclosure agreement, usually within 5 business days of the agreement being in place.