DOC. TRS-L01 — LEGAL / PRIVACY POLICY — REV 2026.08
Privacy Policy
C1Top claim, and how this case is built
Claim C1. TRESONANT.AI LTD handles personal data in a manner an outside reviewer could test, and the page you are reading is that testable version rather than a summary written for reassurance.
Argument. Assurance engineering has a discipline we apply daily on behalf of clients: put the claim first, expose the reasoning that makes it credible, then name the artefact somebody could inspect if they doubted us. A privacy notice written any other way asks readers to trust an assertion whose backing was never shown. We have therefore laid this document out as a safety case. Each numbered clause carries one claim about our handling of personal data, an argument explaining why that claim holds under our operating model, and a pointer to the evidence.
Evidence. Our record of processing activities, held by the directors; the expiry schedule summarised at C16; the recipient list at C14; and the executed engagement contracts governing any work where a client's data enters our systems.
Scope of the argument. The claims cover this website; enquiries, proposals, invoices and supplier arrangements; personal data encountered while we specify, evaluate, constrain and monitor AI systems for clients; and every mobile application we publish through an app store. The governing law is the UK General Data Protection Regulation together with the Data Protection Act 2018, and, for device storage and electronic marketing, the Privacy and Electronic Communications (EC Directive) Regulations 2003.
Precedence. Where we act under a client's written instruction, the processing terms inside that client's contract govern our conduct toward their data and prevail over anything stated here. This case does not weaken those terms; it describes the standing position that applies in the absence of one.
C2Who carries the duty, and how to reach them
Claim C2. A named legal person carries the duty for every use of personal data described here, and a reader can reach a director about it without navigating a queue.
Argument. Accountability that cannot be addressed to somebody is decorative. Wherever this case describes us as controller, the entity bearing that responsibility is TRESONANT.AI LTD, company number NI739783, incorporated in Northern Ireland. Companies House publishes the registered office against that number, and service of formal documents takes effect at whatever address the register shows on the day of service.
One address carries all privacy traffic: sales@tresonant.co. The same inbox receives commercial enquiries, so anything raising a data protection question is lifted out on arrival and passed to a director rather than worked as a lead. Beginning the subject line with the words Privacy request shortens that hop and fixes the date from which our statutory window runs. Written post addressed to the registered office and endorsed Data Protection reaches the same people.
Data protection officer. Article 37 sets three triggers for a mandatory appointment: public authority status, core activities consisting of large-scale systematic monitoring, or core activities consisting of large-scale processing of Article 9 or offence material as controller. We meet none of the three, so no officer is appointed; responsibility rests undivided with the board. That assessment is re-run whenever our service mix shifts materially, and particularly if health data ever reaches us as controller rather than under instruction.
Evidence. The Companies House filing history for NI739783; our entry in the register of fee payers maintained by the Information Commissioner; and the dated note of the Article 37 assessment held with the board papers.
C3Two roles, held apart deliberately
Claim C3. Our capacity is decided by who chose the purpose, never by convenience, and the two capacities are kept in separate systems.
Argument. A firm that builds verification layers for other people's AI necessarily sits close to their data. Confusing the two capacities is how obligations get dropped. The test we apply is simple: whoever settled the purpose and the means is controller for that activity. When we decide — our own marketing, our own hiring, our own accounts, our own applications on the stores — we are controller and answerable directly to the individual. When a client decides, and hands us a documented instruction, we are processor and answerable through them.
Consequence for you. If your details reached us because an organisation engaged us, that organisation owes you the notice and handles your entitlements; write to them first. We will help them answer, and we will tell you who they are if you ask and no confidentiality bar prevents it. If you dealt with us directly, this case is your notice and C19 is your route.
Evidence. The processing record marks each activity with its capacity; engagement contracts state the capacity for that engagement in their opening schedule; and access to client environments is provisioned separately from our own corporate systems.
C4Reading tresonant.co leaves almost no trace
Claim C4. Browsing this website generates operational request records and nothing designed to profile the reader.
Argument. Delivering a page over the public internet cannot happen without the serving infrastructure seeing the request. What we control is whether anything is layered on top of that necessity. Nothing is. No measurement script runs on these pages, no advertising or attribution identifier is written to your browser, no behavioural profile accumulates, and no reader-level report exists for anyone to read. What remains is the record any web server and security edge keeps: an IP address, the moment of the request, the path requested, the response status, the size of the reply, the user-agent string your browser announces and, when your browser sends one, a referring address.
Those records exist to keep the site available and to resist automated abuse, and they are examined only when availability or security prompts a look. Our Cookie Policy sets out the device-storage position in full.
Basis and duration. Article 6(1)(f) covers this, our legitimate interest being a site that stays up and repels attack; the interest is narrow, the data is technical, and the intrusion on a reader is slight. Request and security records expire inside our provider's retention window, which does not exceed thirty days.
Evidence. The absence of any measurement tag is verifiable by reading the page source of any page on this domain; the edge provider's documented log retention supports the duration.
C5Correspondence stays inside the thread it arrived in
Claim C5. An email you send us is used to answer you and to keep the commercial history of that conversation, and it does not seed a marketing database.
Argument. The material is whatever you chose to put in the message: your name, your address, your employer, your role, the technical situation you described, any attachment, and the header data your mail system attaches. We did not solicit it through a form; there is no form on this website, and no field-by-field capture behind the addresses we publish. The purpose is bounded by the exchange — understanding what you need, replying, scoping work if that is where the conversation goes, and holding a record of what was discussed and agreed.
Two bases carry it. Where the exchange leads toward or sits inside a contract, Article 6(1)(b) applies. Where it does not, Article 6(1)(f) does: answering a person who wrote to us is an interest no reasonable correspondent objects to, and the alternative is not replying. Nothing here is used to enrol you in a campaign; see C22 for the electronic marketing position.
A caution about content. Please keep production credentials, live customer records and system secrets out of first-contact email. If a discussion needs that class of material, we will arrange a protected channel before it moves.
Evidence. Threads sit in our business mail tenancy under the retention line at C16; no marketing platform is connected to that tenancy.
C6Client, supplier and applicant files
Claim C6. Business relationships generate records about individuals, and each record has a stated purpose that stops where the relationship stops.
Argument. Three files exist and they behave differently. Client files hold the working contacts on the other side of an engagement — names, roles, addresses, phone numbers, signature blocks, meeting notes, project correspondence and the billing details needed to raise an invoice; they run on Article 6(1)(b) for delivery and Article 6(1)(c) once tax and company law fix the record in place. Supplier files mirror that for the firms and contractors we buy from, on the same pair of bases. Applicant files hold what a candidate sent us and what we wrote down while assessing it; they run on Article 6(1)(b) in the run-up to an employment contract and on Article 6(1)(f) for the short interval afterwards during which an unsuccessful applicant might challenge the outcome.
Boundaries. A client contact is not a marketing contact by default. An applicant's material is not merged into any other file. A supplier's individual contact details are not published or passed on.
Evidence. The processing record lists these three activities with their bases and expiry dates; the expiry dates appear in condensed form at C16.
C7The lawful basis register
Claim C7. Every use of personal data where we decide the purpose has one identified lawful basis, chosen before the processing began and recorded.
Argument. A basis picked retrospectively is not a basis, and swapping between them after the fact is not permitted. The register below is the working version, condensed. Where the basis is legitimate interests, a balancing exercise sits behind the entry, and you can ask to see its outcome.
| Activity | Basis relied on | Where the interest sits |
|---|---|---|
| Serving and defending the website | Art. 6(1)(f) | Availability of the site; resistance to automated abuse |
| Answering an enquiry that has no contract behind it | Art. 6(1)(f) | Replying to someone who wrote to us first |
| Scoping, quoting and delivering an engagement | Art. 6(1)(b) | — |
| Invoices, ledgers, statutory accounts, tax filings | Art. 6(1)(c) | — |
| Assessing a job application | Art. 6(1)(b) pre-contract | — |
| Retaining an unsuccessful application briefly | Art. 6(1)(f) | Defence of a challenge to the decision |
| Security monitoring of our own estate | Art. 6(1)(f) | Integrity of systems holding other people's material |
| Account operation inside a published application | Art. 6(1)(b) | — |
| Optional diagnostics inside an application | Art. 6(1)(a) | Withdrawable in the application settings |
| Establishing, exercising or defending a legal claim | Art. 6(1)(f) | Access to justice for either side |
Evidence. The full register, including the balancing notes, is produced on request to sales@tresonant.co.
C8Material we touch under a client instruction
Claim C8. When a client's data passes through our hands we act only on their documented instruction, and we minimise what passes at all.
Argument. Specifying, evaluating and constraining a live AI system sometimes requires contact with the data that system handles. Our standing preference, written into how we scope work, is that it should not. Synthetic material and structurally faithful fixtures do most of the job; where real records are genuinely required, we ask for a reduced extract rather than a copy of production, and we ask for it to be masked at source unless masking would defeat the test. Where the shape of an engagement means we never see the data at all — because the harness runs inside the client's boundary and returns only pass and fail counts — that is the arrangement we recommend.
Whatever does reach us is held under the processing terms of the engagement contract. Those terms carry the Article 28(3) obligations: instruction-bound processing, a confidentiality duty on everyone with access, security measures matching the risk, written authorisation before a further processor is added, assistance with individual entitlements and with breach duties, and deletion or return when the work ends.
Boundary we do not cross. Client material is not repurposed. It does not train a model of ours, does not become a benchmark, does not appear in a case study, and is not carried into another client's work in any form, including as a derived artefact.
Evidence. The processing schedule of each engagement contract; the scoping note recording why real data was or was not required; and the deletion confirmation issued at closure.
C9Prompts, traces and evaluation corpora
Claim C9. The artefacts peculiar to AI work — prompts, traces, evaluation sets and guardrail decisions — are governed as data stores rather than treated as engineering exhaust.
Argument. Four artefacts routinely carry personal data and are routinely overlooked. A prompt assembled at runtime may pull a customer record into its context window. A trace logged for debugging may preserve that window verbatim alongside the model's reply. An evaluation corpus distilled from real traffic may fossilise real people inside a permanent test asset. A guardrail decision record may quote the very passage it refused to release. Systems we design treat all four as stores in their own right: each is inventoried, each is given an owner, each is assigned a lifetime, and redaction is applied where the payload is not needed for the purpose the store exists to serve.
Evaluation corpora receive the strictest handling because they are the longest-lived. Our design rule is that a corpus should be synthetic or de-identified, and that a corpus built from live traffic requires an explicit written decision by the client as controller, with its own basis and its own expiry.
Evidence. The store inventory produced as part of every reference pipeline we build, which lists each artefact with its owner, lifetime and redaction rule.
C10Model providers, and where inference happens
Claim C10. Where an architecture sends data to a model hosted by somebody else, that is disclosed as a designed property rather than discovered later.
Argument. Many designs a client chooses will call a model running on a third party's infrastructure. When that is the design, whatever the system puts into the context window travels to that provider and is processed there. Which provider, and therefore which jurisdiction and which retention regime, is the client's decision as controller; our job is to make the consequences legible before the decision is taken, implement it under proper contract, and say so plainly when the cheapest option is the wrong one for the material involved.
Three shapes are available and we hold no commercial preference between them: a commercial model interface, where the provider joins the client's processor chain; a model service inside the client's own tenancy, keeping the material inside a contractual and regional boundary they already hold; and a self-hosted open-weight model, where nothing departs at inference time. The third is frequently correct for clinical material and for strict residency conditions.
Checks we run before anything is sent. That the provider's terms place it in a processor role consistent with the client's own obligations, including exclusion from training where required. The region where inference and any logging occur. The provider's own retention of submitted content for abuse monitoring, which on several major platforms is a fixed short period that cannot be switched off on standard commercial plans; we surface that rather than let it be assumed away. Whether zero-retention operation is available on the plan the client actually holds.
Evidence. The architecture note for each engagement records the provider, the region, the retention position and the training-exclusion position at the point of the decision.
C11Decisions taken without a person in the loop
Claim C11. We take no solely automated decision producing legal or similarly significant effects on any individual, and the systems we design for clients are built so that the client does not either, unless they have deliberately chosen to and can defend it.
Argument. Article 22 restricts decisions made without meaningful human involvement where the effect on a person is legal or comparably serious. Nothing in our own operation comes close: we do not score, rank or automatically reject people, and applications are assessed by people reading them.
Inside client work the question is live, because it is exactly what a lending system, a triage system or an eligibility system does. Our reference architecture answers it structurally. Uncertain and refused outputs route to a named human owner rather than proceeding. Human involvement is designed to be real — an owner with authority to overturn, the context needed to exercise it, and time in the workflow to do so — because a reviewer who can only press accept is not involvement at all. The decision logic, its inputs and its overrides are logged so that a person who challenges an outcome can be told why it happened.
Evidence. The escalation design and audit schema in each pipeline specification; and, on the client's side, the Article 22 position recorded in their own assessment.
C12Article 9 categories and offence material
Claim C12. We do not seek special category or criminal offence material as controller, and where a client engagement involves it we work under their condition, not a condition of our own.
Argument. Our own files — enquiries, contracts, suppliers, applicants — have no reason to hold anything from the Article 9 list, and we ask correspondents not to send it. Two exceptions are ordinary and narrow: an accessibility adjustment volunteered for a meeting or an interview, used once and then discarded, and anything a person chooses to disclose to us unprompted, which we do not retain beyond the immediate purpose.
Healthcare engagements are different in kind. Clinical records are Article 9 data and the client, as controller, holds the Article 9 condition and the Schedule 1 safeguard that permits the processing. Our access, if any, is granted under that condition and bounded by the engagement contract, and our design preference is that we work with de-identified or synthetic material and never touch the clinical set. Criminal offence material under Article 10 is treated the same way: no controller processing by us, and controlled access under a client's authority where an engagement genuinely requires it.
Evidence. The engagement contract for any healthcare or enforcement-adjacent work records the condition relied on and the access boundary agreed.
C13Children are outside the intended audience
Claim C13. Nothing we publish is aimed at children, and no service of ours is offered to them.
Argument. Our buyers are engineering, risk and compliance functions inside organisations. This website carries no content directed at a child, our applications are issued for professional use, and we do not knowingly gather anything about anyone under 18. Where an application requires an account, eligibility is stated as adult and the store listing carries the corresponding rating.
If a child's data reaches us despite that, tell us at sales@tresonant.co and we will erase it once we have satisfied ourselves the report is genuine. Where a client's own system processes children's data, the age-appropriate design obligations fall on that client as controller; we support them by designing the controls their assessment calls for.
Evidence. Store listings and their age ratings; the eligibility clause in our Terms.
C14Every recipient, named or categorised
Claim C14. The list of organisations able to see personal data through us is short, written down, and bound by contract.
Argument. A supply chain nobody has enumerated cannot be assessed. Ours is kept deliberately small, each participant is engaged under written terms carrying the Article 28(3) obligations, each is examined before engagement and reviewed afterwards, and none is permitted to act on anything other than our documented instruction. Nothing is sold, rented, brokered or exchanged for value in any circumstance.
| Recipient | Function | Material involved | Where it sits |
|---|---|---|---|
| Cloudflare, Inc. | Name resolution, content delivery, transport security, application firewall and abuse mitigation for this domain | Request and security records; strictly necessary security token | Edge network, ordinarily the node closest to the reader; parent entity in the United States |
| Google Ireland Limited (Workspace) | Business mail, calendar, document storage and internal collaboration | Correspondence, proposals, contract files, meeting records | Predominantly UK and EEA facilities; affiliated entities include Google LLC |
| Apple Distribution International Ltd / Apple Inc. | Distribution and billing for applications on the App Store; developer reporting where a user has opted to share it | Download and purchase records; aggregate store reporting; crash reports | Ireland and the United States |
| Google Ireland Limited / Google LLC | Distribution and billing on Google Play; Play Console reporting; delivery of the typefaces this site requests | Download and purchase records; aggregate store reporting; crash reports; font request headers | Ireland and the United States |
| Accountancy and bookkeeping practice | Statutory accounts, tax and payroll filings | Billing and accounting records | United Kingdom |
| Banking and payment institutions | Settling and receiving payment | Payee identity and payment references | United Kingdom and EEA |
| Professional advisers under duties of confidence | Legal, insurance and audit advice when a matter requires it | Only the material the matter requires | United Kingdom |
| Public authorities | Disclosure compelled by law or by a court | Only what the instrument compels | United Kingdom |
In processor engagements the chain is fixed by the client's contract. We add nobody to it without their prior written authorisation, and the current list for an engagement is available to that client on request.
Corporate events. If the business or part of it were ever transferred, personal data would move with the relevant contracts under confidentiality, and anyone materially affected would be told before the arrangements governing their data changed.
Evidence. Executed processing terms with each recipient above, and the dated due diligence note preceding each engagement.
C15Movement of data beyond the United Kingdom
Claim C15. Data leaves the United Kingdom only where a Chapter V mechanism is already in place for that route.
Argument. Several recipients at C14 are established elsewhere, or are UK and EEA entities inside groups whose support functions are not. Each route is mapped to a mechanism before the route is used, and the derogations in Article 49 are not treated as a standing arrangement for anything routine.
| Route | Mechanism | Note |
|---|---|---|
| To the EEA, or to any state covered by UK adequacy regulations | Adequacy under s.17A DPA 2018 | Monitored for withdrawal; a contractual mechanism would replace it |
| To a US recipient certified under the UK extension to the EU–US framework | The UK–US data bridge | Used only where we have confirmed a live certification covering that data type |
| To a third-country recipient we contract with directly | UK International Data Transfer Agreement | Preferred where the whole relationship is governed by UK law |
| To a recipient already operating on EU standard contractual clauses | Those clauses plus the UK Addendum | The practical route with most global suppliers |
| Onward movement by somebody in our chain | Flow-down terms in our contract plus that party's own Chapter V mechanism | Confirmed during due diligence, before engagement |
| Movement inside a client engagement | As instructed by the client as controller and recorded in the contract | No region change without a documented instruction |
Risk assessment. Where the mechanism is the International Data Transfer Agreement or the UK Addendum, we complete a transfer risk assessment first, weighing the destination's legal environment, the sensitivity and volume involved, and the technical protection applied in transit and at rest. Where the assessment cannot be satisfied, the route is not used and the design changes instead.
Evidence. Executed transfer instruments and the dated assessments behind them; copies of the assessment relevant to your data are available on request.
C16Each store has a stated end date
Claim C16. No store runs without an expiry rule, and retention is bounded by purpose rather than by storage being cheap.
Argument. Data kept past its purpose is pure liability: it can still leak, still be demanded in litigation, still be misused, and no longer earns anything. Every store is therefore assigned an expiry at the moment it is created, and the schedule is reviewed annually. Where a legal hold applies — an actual or anticipated claim, a regulatory demand — the affected material is frozen until the matter closes, after which the ordinary rule resumes.
| Store | Lifetime | Why that length |
|---|---|---|
| Website request and security records | Up to 30 days at the edge | Long enough to investigate an incident, short enough to be no profile |
| Enquiry threads that led nowhere | 24 months from the last message | Conversations resume; beyond two years they do not |
| Client engagement correspondence and working files | 6 years from the close of the financial year in which the engagement ended | Aligned to the limitation period for a contractual claim |
| Contracts, invoices, ledgers and tax records | 6 years from the close of the relevant financial year | Company and tax legislation fixes this |
| Client data held as processor | Deleted or returned on closure, per the engagement contract | The client sets it; their instruction governs |
| Applications from unsuccessful candidates | 6 months from the decision | Time to raise and resolve a challenge |
| Account records inside a published application | Until deletion is requested; residual copies clear within 30 days | Account deletion is described at C21 |
| Encrypted backups | Rolling window not exceeding 90 days | Recovery from failure or ransom; overwritten in sequence |
When a lifetime expires the record is deleted, or is irreversibly stripped of anything identifying so that what remains cannot be linked back to a person. Anything surviving in an encrypted backup is inert, is not restored to answer routine queries, and clears on the backup cycle.
Evidence. The retention schedule held by the directors, of which the table above is the published summary.
C17Controls that stand between a store and an attacker
Claim C17. Technical and organisational measures are proportionate to the risk our work carries, which is higher than our size suggests because our access is privileged.
Argument. A firm holding credentials to other organisations' AI infrastructure is a worthwhile target regardless of headcount, so the controls are set against that exposure rather than against our size. They fall into four groups.
Confidentiality in transit and at rest. Transport security at TLS 1.2 or above with modern cipher suites and strict transport enforcement on this domain; administrative access only over authenticated encrypted channels; whole-disk encryption on every company device; encryption at rest on managed storage holding personal data, and on backups. Extracts that must move are encrypted before they move and the key travels by a different channel; personal data is never attached to an unencrypted message.
Restriction of access. Least privilege as the default, granted per role and per phase and withdrawn at role change or engagement closure; named individual accounts with no shared credentials anywhere near personal data; multi-factor authentication enforced across mail, cloud consoles, source control, deployment and administrative interfaces, with phishing-resistant factors where a platform supports them; secrets held in a managed store, never in source, tickets or chat, and rotated on personnel change or suspected exposure; production, staging and development separated, and each client engagement isolated from every other.
Detection. Privileged actions recorded with actor and timestamp, held apart from the systems they describe; alerting on authentication anomalies, unexpected privilege change and unusual outbound volume; logs designed to carry no personal data payload, with redaction at source where they otherwise would.
People and premises. Confidentiality undertakings before access; data protection and security induction, refreshed annually and after any incident; company devices encrypted, patched, locked and monitored; client data never processed on personal equipment; and change control on anything that alters a data path.
Honest limit. Controls reduce risk; they do not abolish it. Nobody who tells you otherwise is describing a real system.
Evidence. Configuration of the controls above is demonstrable to a client's assessor under a confidentiality undertaking, and forms part of our response to security questionnaires.
C18What happens on the day something goes wrong
Claim C18. A breach is handled on a defined clock, and the people who need to know are told before it is comfortable to tell them.
Argument. The regulated definition is broader than an intrusion: it covers destruction, corruption, exposure or unauthorised access, however caused, including by our own error. Our sequence is fixed. Contain — revoke credentials, isolate the affected component, stop the flow. Assess — establish what was involved, whose data, how much, in what form, and what an attacker could do with it. Notify — where we are controller and the risk to people is anything beyond remote, we report to the Information Commissioner within seventy-two hours of becoming aware, filing an initial report on partial facts rather than waiting for a complete picture. Where the risk to individuals is high, we tell those individuals directly, describing plainly what happened and what they should do. Learn — a written review identifies the cause and the change that prevents a repeat, and the change is tracked to completion.
As processor the duty runs differently: we alert the client without undue delay after becoming aware, give them what they need to make their own notification decision, and take no notification step of our own except at their instruction or where the law compels us.
Evidence. The incident log, which records every event, its assessment and its outcome regardless of whether it reached the reporting threshold.
C19What you may require of us
Claim C19. Your statutory entitlements are exercisable in practice, free, and by writing one email.
Argument. Entitlements that exist on paper and fail in operation are worse than none, because they mislead. Where we are controller you may require the following, and the mechanism is a message to sales@tresonant.co.
- Confirmation and a copy. Whether we hold anything about you and, if so, a copy of it together with the surrounding information — purposes, categories, recipients, lifetime, source and your onward options.
- Correction. Repair of anything inaccurate, and completion of anything misleading through incompleteness.
- Erasure. Deletion where the data is no longer needed for its purpose, where consent was the basis and has been withdrawn, where you have objected successfully, or where the processing was unlawful.
- Restriction. Suspension of use while a dispute about accuracy or about a legitimate interests balance is resolved.
- Portability. Where the basis is consent or contract and the processing is automated, a machine-readable export you can take elsewhere, or direct transmission where that is technically workable.
- Objection. A challenge to any processing resting on legitimate interests, which we must stop unless we can show compelling grounds that override your position. Objection to direct marketing is absolute and takes effect immediately.
- Withdrawal of consent. Where consent was the basis, withdrawal at any moment, with no effect on what was lawful beforehand.
- Freedom from solely automated decisions of the kind Article 22 restricts, which as described at C11 we do not take.
How the request runs. We may ask for enough information to be sure who you are, because handing your data to an impostor would be the worse failure; we ask for proportionate proof and nothing more. The substantive answer is due within one calendar month of receipt, extendable by up to two further months for genuinely complex or numerous requests, in which case we tell you inside the first month and explain why. There is no charge unless a request is manifestly unfounded or excessive, and if we ever decline one we will say so, give our reasons, and set out where to take it next.
Where we are processor, the request belongs to the client who instructed us. Send it to them; we will pass on anything that reaches us and support their response.
Evidence. The rights log records each request, the date of receipt, the date of answer and the outcome.
C20Escalation, and the regulator behind it
Claim C20. Disagreement has a route that does not depend on our goodwill.
Argument. Raise it with us first if you are willing — a director reviews complaints personally and can usually fix a problem faster than a regulator can look at it. That is a preference, not a precondition, and you are entitled to go straight to the supervisory authority whether or not you have written to us.
The authority for the United Kingdom is the Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF. Its helpline is 0303 123 1113 and complaints can be lodged through ico.org.uk. Complaining costs nothing and requires no representation. If you live or work in the EEA, or the matter arose there, your national supervisory authority may also be competent.
Evidence. Our fee registration with the Commissioner, searchable on the public register held by that office.
C21Applications published through the stores
Claim C21. Applications we publish collect what their features require and disclose it in the place a store reviewer and a user will each look.
Argument. This clause governs every mobile application TRESONANT.AI LTD publishes on the App Store or Google Play, including companion, monitoring and evaluation tools. We are controller for such an application unless it is deployed under an enterprise agreement making the client organisation controller, which will be stated in that agreement and inside the application itself.
What an application may hold. Account data — an address, a display name, a credential held only as a hash or a federated token, and workspace membership where the deployment is organisational, on Article 6(1)(b). User content — configurations, saved views, annotations and alert rules you create, on Article 6(1)(b), and yours under our Terms. Technical data — device model, operating system and application version, locale, and a per-installation identifier used for session handling and notification delivery, on Article 6(1)(b) with Article 6(1)(f) for security. Optional diagnostics, purchase records and support correspondence as described below.
Permissions. Each permission is requested at the point its feature is first used rather than at launch, with the reason on screen. Declining leaves everything unrelated working, and every permission can be revoked afterwards in the operating system settings for that application.
Apple: App Tracking Transparency. Our applications do not track you in the sense Apple's App Tracking Transparency framework defines. No advertising, attribution or data-broker component is embedded; the Identifier for Advertisers is not read; and no identifier of ours is linked with data from other companies' apps or sites for advertising or measurement. Consequently no tracking prompt is presented — the framework requires one only where tracking occurs, and if that ever changed the prompt would appear and consent would be sought before anything began.
Google Play: Data Safety. The Data Safety section of each Play listing is completed to match the behaviour described here: the categories collected, whether each is shared, whether each is optional, that transmission is encrypted, and that account deletion is available in the application and by written request. Where a listing and this clause ever diverge, tell us and we will correct whichever is wrong.
Diagnostics and crash data. Crash and performance reporting is optional, off unless you enable it, and enabled or disabled at any time in the application's settings; where you enable it, Article 6(1)(a) applies and the report is used to fix defects.
Purchases. Where an application is paid or carries a subscription, the store handles the transaction and we receive confirmation and periodic settlement reporting, not your card details. Cancellation and refunds run through the store's own process, described in our Terms.
Account deletion. You can delete your account from inside the application, and you can require account deletion by writing to sales@tresonant.co from the registered address. Deletion removes the account and its content from live systems immediately and from encrypted backups within thirty days, leaving only records a statutory duty requires us to keep, such as a transaction record for tax. Removing the application from a device clears local storage but does not by itself delete the account.
Evidence. The store listings themselves, the in-application settings screens, and the deletion confirmation issued when a written request completes.
C22Marketing under PECR
Claim C22. Electronic marketing from us is scarce, relevant and instantly stoppable.
Argument. We do not buy lists, do not append addresses from other sources, and do not sell or share contact details for anyone else's marketing. Direct approaches to a corporate address about services adjacent to something already discussed are permitted by the electronic communications rules and are the only routine outbound contact we make. Where anything resembling a newsletter is sent to an individual subscriber address, it goes only to people who asked for it.
Every message identifies us, states why it reached you, and carries a working exit that we honour on receipt rather than at the next cycle. Replying with the word stop works equally well. Withdrawal ends the marketing and nothing else: we will still answer your questions and still service a contract.
Evidence. The suppression list, which retains the minimum needed to ensure a withdrawal is not undone by a later import.
C23Amending this case; document control
Claim C23. Changes to this case are dated, versioned and, where they matter to you, announced rather than slipped in.
Argument. A privacy notice that changes silently is a notice nobody can rely on. Practice moves — a new recipient, a new store, a changed lifetime — and the document must move with it. Every revision carries a fresh version number and a fresh effective date in the block that opens this document. Where a change materially affects an individual, we describe it in a short note near the top for at least thirty days, and where a change would need consent we ask for consent before it takes effect rather than announcing it afterwards. Continuing to read the site is not consent to anything.
Reaching us. Everything in this case is addressed to sales@tresonant.co. Open a rights request with the words Privacy request in the subject line; open a breach report with the word Security. Written post to the registered office endorsed Data Protection arrives with the same people. If you are writing about an entitlement under C19, say so in the opening line and tell us how you would prefer the answer to come back.
DOC. TRS-L01 · Assurance case, personal data · Issue 3.0 · Effective 15 August 2026 · Supersedes issue 2.0 of 5 August 2026. Companion documents: TRS-L02 Terms and TRS-L03 Cookie Policy.