Security and data handling
What TRU Network stores, what remains under your control, the safeguards that enforce this boundary, and how to report a vulnerability.
EFFECTIVE 11 SEPTEMBER 2026 · VERSION 2.2
1. Short answer
TRU Network separates our software from your data. Your TRU Board is held in the sole tru.json file in your own OneDrive and remains under your control. TRU Home data stays on your own hardware. TRU Card is the exception, because a hosted public profile and its reporting are the service.
We do not sell personal information, and we do not use customer board content to train AI models.
We state the boundary precisely. TRU Network does not store a hosted copy of your board, but the browser application does send the rows needed for a requested operation to our server to be processed in memory for that response. Your account data is stored by us in the ordinary way.
2. TRU Board
TRU Board opens and saves only the existing tru.json master in your own OneDrive through Cloud Connection. BOARD does not create another board file, open a loose local board, or use another storage location. Documents attached to an action remain in your connected OneDrive location, under your retention and access policy.
The browser application calls TRU Network server routes for licence checks and for product decisions such as board rendering, status calculation, folders, templates, printing and AI-assisted wording. Those routes sit behind a valid session and a product grant. Request data is processed in memory to produce the response. It is not written to a TRU-hosted copy of your board and is not written to our application logs.
Where a feature needs Microsoft OneDrive access, the browser uses your own signed-in Microsoft session to read and write your file. We do not convert your board into a TRU-hosted database.
3. Browser software and intellectual property
Any web application has to send some software to the browser. A signed-in subscriber can inspect the page structure, styling and client-side workflow, and we do not describe that browser shell as secret.
The parts that make TRU Board valuable — server decision logic, prompts, licence and session enforcement, source-master files and secrets — are not delivered as public browser files. Browser files are checked so that they do not contain server paths, private keys, source-master paths or customer board data.
4. Accounts and administrative access
Product access requires a valid user session and a product grant. The public website serves branding, legal pages and sign-in screens; the application and its server routes require authorised access.
Administrative access to customer-facing systems is more tightly controlled than ordinary access. It requires a valid session, a request from an approved origin using an approved method, multi-factor authentication at the higher assurance level, and a separate administrative grant that is current and unexpired. A session that holds only single-factor authentication is refused even where the account is an administrator. Withdrawing or expiring a grant takes effect on the existing session immediately, without waiting for it to expire.
Administrative account data, such as customer name, email address, company, product grants and support notes, is stored so that we can operate the service.
5. TRU Card and visitor privacy
TRU Card profiles are hosted because they are meant to be reached by NFC card, QR code or link. Profile content you publish is public by design. Views and taps are recorded for the cardholder’s reporting, and only where the visitor has consented.
Card analytics are built to collect as little as possible about the visitor:
- Nothing is stored on the visitor’s device, and no record is created, until the visitor answers the consent banner. Card pages set no cookies
- The visitor’s IP address is never stored. It is converted to a keyed irreversible value inside the edge service and used only for rate limiting; the address field on the analytics record is written empty and the raw address is never passed to the database
- No IP geolocation service is used. Only the two-letter country supplied by our network provider is retained; town, city and region are not recorded
- Query strings and fragments are stripped from a page address before it is stored
- Event types, sources and actions are validated against fixed allow-lists, and card identifiers, event identifiers, body size, content type, method and browser origin are all validated before anything is accepted
- Per-actor, per-card-per-minute and per-card-per-day rate limits are enforced, and duplicate or replayed events are rejected, so a report cannot be inflated by flooding a card
6. TRU Home
TRU Home runs on hardware in your property. Camera footage, sensor readings, calendars, shopping lists and device history stay on that hardware unless you ask us to support or configure your system. Each household system is authenticated separately, and one household cannot reach another’s system.
7. BOARD AI
BOARD AI is inactive until the account holder activates it and accepts the additional data-sharing notice. TRU Board Secure operates with no AI provider receiving board content.
When it is active, only the board information and the external sources the customer connects are processed, and only the content required for a requested operation is sent, through protected server routes. Source emails, transcripts and cloud files stay with the connected provider wherever technically possible; full source copies are not written into the board file, and email, transcript and board content are not stored in the BOARD AI credit database. Output is a proposal: a person must approve it before the board changes or anything is sent externally. Customer content from BOARD AI is not used to train general-purpose models.
8. Platform controls
- Encryption in transit. All traffic is served over HTTPS with HTTP Strict Transport Security, and insecure requests are upgraded
- Browser hardening. Every response carries a Content Security Policy, plus
X-Content-Type-Options,X-Frame-Options,Referrer-PolicyandPermissions-Policy. Framing is denied, object and frame sources are blocked, and form submission and connections are restricted to known origins - Database isolation. Row-level security is enabled on customer tables and there are no policies granting direct client access, so direct access from a browser is denied by default. Anonymous attempts to read internal tables over the public interface are rejected
- File storage. Private buckets are not publicly readable, and both public and private buckets enforce a maximum file size and a fixed list of permitted file types
- Privileged database routines run with a fixed search path and are not executable by anonymous or ordinary authenticated roles
- Private source and configuration paths are blocked at the edge before static delivery, so repository, function and test directories are not served
- Secrets are held in the platform secret store and in server environment configuration, never in the source repository. We scan the repository, including its full commit history, for exposed credentials, and rotate and disable any key that has been exposed
9. Retention and deletion
Retention is enforced by scheduled deletion, not by intention. Card engagement records are deleted 395 days after creation, and abuse-prevention records after 30 days, by a purge job that runs daily. The full retention schedule, including account, billing and security records, is set out in our privacy policy.
10. Service providers and hosting
We use established providers for content delivery and network security, website and application hosting, database and authentication services, transactional email, and payments. They process data only as needed to provide those services and only on our instructions. We aim to keep personal data in the United Kingdom or the European Economic Area, and where a provider processes data elsewhere we rely on the safeguards described in our privacy policy. A current list of our processors is available on request.
11. Reporting a vulnerability
If you believe you have found a security vulnerability in a TRU Network service, please report it to security@tru-network.com. Include enough detail to reproduce the issue, and give us a reasonable opportunity to fix it before disclosing it publicly.
We will acknowledge a report within five working days, keep you informed of progress, and credit you when a fix is released if you would like us to. We do not currently operate a paid bug bounty.
What is in scope, and what is not
Testing is permitted against tru-network.com and its subdomains, and against a hosted TRU Card profile you control. The following are not permitted, and are not covered by the assurance below: accessing, modifying or downloading data belonging to another customer; denial-of-service or load testing; social engineering, phishing or physical attacks against our people or premises; and testing against a customer’s own TRU Home hardware or connected accounts.
Our assurance to you
Where you make a good-faith effort to comply with this policy, act only against systems in scope, avoid privacy violations and service disruption, and report promptly, we will not pursue legal action against you in relation to your research, and we will make clear that your work was authorised if a third party raises it with us. Nothing in this policy authorises testing against systems that are not ours. This paragraph is a statement of our intent and does not bind any other party.
Clause 5 of our terms of use prohibits probing our infrastructure other than under this policy. Reporting under this policy is the permission it refers to.
12. Incident response
Suspected incidents are triaged on receipt, contained, investigated and recorded, and any credential involved is rotated. Where a personal data breach is likely to result in a risk to people’s rights and freedoms, we notify the Information Commissioner’s Office within 72 hours of becoming aware of it, and we notify affected individuals without undue delay where the risk is high. Business customers are notified without undue delay where an incident affects data we process on their behalf.
13. Assurance and certification
We would rather be accurate than impressive. TRU Network does not currently hold ISO/IEC 27001 certification, a SOC 2 report, or Cyber Essentials, and this page should not be read as claiming any of them.
What we do hold is evidence. The controls described above are verified against the running systems and recorded as dated evidence, with independent verification of our public response headers, and that record is reviewed as the products change. If you are assessing TRU Network as a supplier and need a security questionnaire completed or supporting evidence provided, write to security@tru-network.com and we will respond.
14. Security contact
Security reports and supplier assurance questions: security@tru-network.com. Data protection questions and rights requests: privacy@tru-network.com. Postal address: TRU Network Ltd, 71–75 Shelton Street, Covent Garden, London WC2H 9JQ.