Privacy Policy

The position

A privacy notice earns nothing by being long. It earns its place by being answerable. We have therefore set ours out the way we would put a difficult question to a board: numbered items, one subject each, with the firm's position stated plainly and the consequences drawn out rather than left for the reader to infer.

Our work makes that necessary. A single engagement can have us reading a client's pipeline, sitting with the people who work it, designing a better process, and then building and running the system that carries it. Personal data is present at every one of those stages, and it belongs to different people in each.

What this means in practice

Each item below states whose material it concerns and which of our two capacities applies. You do not have to read the whole document. Find the items that describe your relationship with us and read those; the index above is ordered so that the audience is visible from the heading.

The position

THE REVENUE HOUSE LIMITED trades as The Revenue House and is a company registered in Northern Ireland under number NI740029. We work from Belfast. Our business is revenue-operations consulting joined to custom software delivery, sold to organisations rather than to individuals.

What this means in practice

One address carries everything on this subject: enquiries@therevenuehouse.uk. Questions, rights requests, complaints, security reports and requests for our processor terms all arrive there and are read by the person accountable for them. If a matter is time-critical, open the subject line with the word URGENT and the words data protection so it is triaged ahead of commercial mail.

Written correspondence should be addressed to the data protection contact at our registered office. That address is on the public record at Companies House against company number NI740029, and it is the address at which formal service takes effect.

The position

Data protection law separates the organisation that decides why material is handled from the organisation that handles it on somebody else's written instruction. The first answers to the individual and must justify the purpose; the second must stay inside its instructions and answer to whoever gave them. A single firm can occupy both chairs at different moments. Ours does, daily.

What this means in practice

We are the deciding party — the controller — and this memorandum is our notice to you, in respect of: people who read this website; anyone who writes to us or takes a first call; named contacts at organisations we are quoting for or working with; the administration of an engagement, meaning contracts, scoping, invoices, correspondence and our own working papers; suppliers, subcontractors and job applicants; and users of any application we publish under our own name.

We are the instructed party — the processor — and our client occupies the deciding chair, in respect of: everything we see inside a client's own systems during a diagnostic; notes and recordings naming a client's staff; material moving through software we are building; and everything held in a system we operate under a Build & Run retainer. In that capacity we hold no purposes of our own and take no decisions about your material, which is why Item 12 tells you to direct requests to the organisation that engaged us.

The position

Responsibility for this subject sits with the company's director, who is also the accountable contact named on every engagement. That concentration is deliberate: in a firm this size, splitting privacy accountability from delivery accountability produces two people each assuming the other looked.

A statutory data protection officer is exacted from public authorities; from bodies whose central activity is watching individuals systematically and on a large scale; and from bodies whose central activity is handling the most sensitive categories in bulk. Our work sits outside all three descriptions, so the office has not been created. That assessment is revisited whenever our activities change, and an appointment would be recorded here.

What this means in practice

Most UK organisations owe the ICO an annual data protection fee. Ours is paid, and the register entry is kept current. We do not print a registration reference on this page, because a number typed into a web page is worth less than the register itself; the ICO's public register at ico.org.uk can be searched under our company name.

The position

Capacity: controller. This site carries no forms, no accounts, no comment threads and no embedded third-party content. Material reaches us by exactly two routes — the technical record of a page being served, and an email you choose to send.

What this means in practice

Measurement tooling, advertising technology and audience-building are absent from this site by choice, and we neither purchase nor append third-party data about the people who read it. Any change to that arrives in the Cookie Policy before it arrives on the site, and Item 27 governs how you are told.

The position

Capacity: controller. This item concerns the individuals we deal with at an organisation — the person who signs, the person who briefs us, the person who pays the invoice. It does not concern the organisation's own records that we see while working, which are the subject of Items 12 to 16.

What this means in practice

The position

Capacity: controller. Everyone who supplies us, subcontracts to us or applies to work with us generates a small file. Credit scoring, background screening and automated sifting of applications play no part in any of it; were a role ever to demand one of those, the person concerned would be told before it happened.

What this means in practice

The position

Capacity: controller, for any mobile application released on the App Store or Google Play under our own developer account. Where we build an application for a client and it ships under the client's account, the client takes the deciding chair and Items 14 and 15 govern our part instead. Item 24 carries the operational detail; this item carries the record of what is collected and why.

What this means in practice

Personal data is not sold. Advertising kits are absent from our builds, advertising identifiers are never read, precise location is never requested, and nothing about you is followed into anybody else's product.

The position

Capacity: controller. Every use listed in Items 05 to 08 rests on a named lawful basis, and the basis appears in the table beside the use rather than in a general statement at the foot of the page. Where the basis is a legitimate interest, the law requires us to name that interest, show the handling is genuinely necessary for it, and set it against your rights. We have carried out and written down that exercise for each one.

What this means in practice

The position

The law fences off a narrow class of material — anything revealing ethnic or racial origin, political opinion, religious or philosophical conviction, or membership of a trade union; genetic and biometric identifiers used to pick a person out; and anything touching health, sex life or sexual orientation. Material about offences and convictions sits under a separate and equally strict rule. Neither may be handled without a specific condition on top of an ordinary lawful basis.

What this means in practice

In the deciding chair, none of it is any use to us. Readers, correspondents, client contacts, suppliers and app users are never asked for material of that kind, and the applications we publish are working tools with no health, biometric or comparable function. Two narrow exceptions exist and both are handled at arm's length. Where you need a meeting run differently, a document in another format, or an adjustment during recruitment, we use what you tell us for that adjustment and nothing else, relying on explicit consent or, in a recruitment context, the employment condition in Schedule 1 of the Data Protection Act 2018, and we keep it only while the adjustment is live. Where such material reaches us unasked, we put it to no use at all and delete it, or wall off access where it sits inside a record we are obliged to keep.

In the instructed chair, it depends entirely on the client. A client's systems may well hold material of this kind: a clinical record, a charity's beneficiary file, an employment system. Where an engagement is going to expose us to it, the point is settled before anyone opens a system. The engagement letter and processing agreement name the categories involved. We ask the client to confirm which condition it relies on, that being its determination to make and not ours. We ask for redacted, pseudonymised or field-limited extracts wherever the analysis can be done without the sensitive field, because a funnel review very rarely needs a clinical code or a protected characteristic to reach its finding. Where the material genuinely cannot be excluded, the additional measures at Item 20 apply and working copies are destroyed at the close. An instruction to handle offence data is declined unless the client identifies its condition and the appropriate policy document that section 10 of the Data Protection Act 2018 requires of it.

The position

Capacity: controller. What we sell is bought by organisations, this website addresses people making commercial decisions, and the applications we publish are working tools for adults at work. None of it is aimed at a child, and we do not knowingly gather personal data from anyone under thirteen. Our age ratings and target-audience declarations on both stores are completed on that footing.

What this means in practice

In the instructed chair the position can differ, because a client's systems may hold records about children — a school, a clinic, a family service. The client then occupies the deciding chair and must satisfy itself as to its own basis and its obligations under the age-appropriate design code. We treat material of that kind as carrying elevated risk under Item 20, and we say so at scoping rather than discovering it mid-build.

The position

Capacity: processor, on the client's instruction. This is the most exposed thing we do. Finding where revenue escapes a business means reading records of real people — the enquiry that never converted, the deal that stalled, the customer who left, and the employees who handled each of them.

What we typically see: contact records with names, working addresses, roles, lead source, stage history, record owner, activity timestamps, free-text notes a salesperson wrote about an individual, and stated reasons for loss; deal data carrying values, close dates, discount history and named people on both sides; campaign data covering list membership, engagement, form submissions and consent records; support records whose contents unavoidably name customers; billing and retention data; and performance figures broken down by named salesperson, which is personal data about an employee and is treated as such throughout.

What this means in practice

• Instruction precedes access. No system is opened until the engagement letter and processing agreement are signed and the client has documented what we may reach and for what purpose.
• The narrowest extract that answers the question. Fields the analysis does not need — free-text notes, personal addresses, home details — are excluded or masked before anything is exported.
• Read-only unless the scope demands otherwise, and then only for as long as it demands, always under named accounts rather than a shared login, so the client's own logs record who did what.
• Analysed where it lives wherever that is possible. Where an extract is unavoidable it goes to a dedicated, access-controlled, encrypted location that is named in the engagement record.
• No second use. The material trains nothing, seeds no benchmark, informs no other client's work and enriches nothing of ours. Item 16 states that without qualification.
• Returned or destroyed at the close, at the client's election, confirmed in writing, with our credentials surrendered at handover.

A client's own transparency notice and record of processing has to account for an adviser reading this material, and we raise that at scoping rather than assuming it was handled. Where an intended use looks plainly outside what a client's customers were told, we say so — a processor that spots an instruction likely to breach the law is obliged to speak.

The position

Capacity: processor on a client engagement; controller for our own first calls before any engagement exists. Diagnosing a revenue engine means sitting with the people who run it, and designing the fix means workshopping definitions with them. Both produce notes about named individuals: who owns which stage, where a handover fails, who quietly works around a system, and occasionally a candid view of a colleague.

What this means in practice

• People are told at the start. Every interview opens with who we are, that we are working for their employer, what becomes of the notes, and that findings go to the client. Nobody should learn afterwards that they were being written down.
• Notes describe a process, not a performer. We write no appraisals, and we decline an instruction to feed interview material into a disciplinary or redundancy exercise — that is a different activity carrying different safeguards, and we say so rather than quietly comply.
• Attribution is kept to a minimum. Findings are reported by theme. Where a role is unique, so that naming the role identifies the person, we tell the interviewee at the time that their contribution cannot realistically be made anonymous.
• Raw notes stay with us. The client receives the diagnostic and its evidence; our notebooks are working papers under Item 19, held with access restricted.
• Nothing travels informally. Where someone discloses a matter the client genuinely must know about, we tell that person we intend to raise it before we raise it.

Recordings are a decision, never a default. A recording preserves a person's voice, wording and manner, so written notes are our normal method and audio is captured only where a client has asked for it and the request is documented in the engagement. We announce at the start what is being captured, why, and how long it survives, and we ask whether anyone objects; an objection stops the recording, and a latecomer is told. On our own first calls the basis is your consent, refusable with no consequence for the conversation. Recordings exist to confirm we captured a process correctly and never to monitor how someone performs. Transcripts inherit the identical treatment — same access limits, same retention, same destruction. Automated transcription is disclosed to the client, listed as a sub-processor under Item 17, and configured so that content cannot train the provider's models; a service reserving the right to train on customer content is not adopted. Audio is destroyed 90 days after the stage it was made for, or earlier on instruction, because the written finding carries the substance and the audio does not need to outlive it.

The position

Capacity: processor, on the client's instruction. Personal data moves through the whole of our delivery work: internal business systems, workflow automation, integrations stitching together sales, billing, support and marketing tools, and the dashboards that report on all of it.

What this means in practice

While a system is being built. Before a schema is written we ask what personal data the thing genuinely requires, and the answer is usually less than the brief assumed — a dashboard reporting pipeline value needs stages and amounts, not customer names. Development and staging environments run on synthetic or pseudonymised material. Where a defect can only be reproduced against live records, that is time-boxed, agreed specifically, and cleaned up afterwards. Every account is named, its reach is scoped to the task, and what it opens is logged. Retention and destruction rules are built to the client's own policy, so the system does not silently become a permanent archive. Where a system holds records about individuals we build in the ability to find, export, correct and remove one person's records, so the client can answer a request without needing an engineer.

While a system is being run. Under a Build & Run retainer we remain the instructed party and additionally: hold the environment to the measures at Item 20; take, encrypt and test-restore backups on the agreed cycle; keep operational logs from which personal data is omitted wherever a technical reference will serve; patch dependencies on a defined cadence and out of cycle where a vulnerability is serious; report any breach to the client without undue delay under Item 21; and, when the retainer ends, export the client's data in a usable form, hand over infrastructure and credentials, destroy our copies and confirm that in writing. The client owns its code, its data, its credentials, its documentation and its diagrams throughout.

The position

Where we hold the instructed chair we contract on terms satisfying Article 28(3) of the UK GDPR. Those terms are not decoration; they are the mechanism by which a client remains answerable for material it has let out of its own building.

What this means in practice

• We act only on documented instructions, movement of material out of the United Kingdom included, unless the law compels us otherwise — and in that event the client hears from us beforehand, save where the law forbids us to say so.
• Everyone authorised to touch the material is under a binding duty of confidence, and the technical and organisational measures at Item 20 apply.
• We appoint a sub-processor only with the client's written authorisation, impose equivalent obligations on it, stay fully answerable for what it does, and give advance notice of a change with a right to object.
• We assist the client in answering requests from individuals, and with security, breach reporting, impact assessments and prior consultation, so far as the information sits with us.
• At the close of the services we destroy or return everything at the client's election, and destroy remaining copies unless the law requires us to keep them.
• We make available what a client needs to demonstrate that these obligations are being met, and we allow and contribute to an audit by the client or its appointed auditor, on reasonable notice and under confidence.
• Where an instruction appears to us to breach data protection law, we say so at once rather than complying and raising it later.

Our standard processing agreement is available on request at enquiries@therevenuehouse.uk. We will equally sign a client's own paper where its terms are workable for an engagement of this shape.

The position

Material belonging to one client is not used to do work for a different one. Not as a template, not as a comparison, not as a source of leads, not as a workshop illustration, and not as input to any tool or model of ours. Every engagement stands on its own.

What this means in practice

Benchmarks require permission and genuine anonymisation. Comparative figures — conversion by stage, cycle length, the usual causes of churn — are useful, and we may build them in time. Two conditions govern that, and both must hold. The client must have given specific, written, revocable permission, separate from the engagement letter. And the contribution must be effectively anonymised before it leaves the engagement, meaning aggregated so that neither an individual nor a client organisation can be picked out by us or by anybody else, taking account of every means reasonably likely to be used, including combination with other material we hold. Where a sample is too small for that to hold true, it does not go in. Pseudonymised material, where a key linking back still exists, is not anonymous, remains personal data, and is never used for this purpose.

Published work requires the client's signature. Where we write about real work, the client is named only with written permission and approves the text before it appears; no employee or customer of the client is identified without their own agreement; and figures are either approved or generalised past the point of tracing. Permission is revocable, and a withdrawal takes the piece down.

Client material trains no models. We do not use client personal data to train, tune or evaluate machine-learning models, ours or anyone else's. Where a tool exposes a setting controlling whether customer content feeds the provider's models, we turn it off, and where a tool refuses to expose that setting we do not put material of this kind into it.

The position

Our supply chain is deliberately short, because every additional party is another organisation whose security we have to stand behind. Each one is engaged under a written contract containing data protection terms, and each is assessed under Item 07 before anything reaches it.

What this means in practice

Several rows describe a function rather than naming a company. That is because certain tooling decisions are taken when the first application or the first operated system ships, and we would rather hold a slot open than print the name of a provider we are not using. Each will be named in this table before it handles personal data.

Changes to sub-processors. Our processing agreement gives general authorisation for the providers listed at the start of an engagement and commits us to at least 30 days' written notice before one is added or replaced. Within that window a client may raise a reasonable data protection objection; an alternative is then sought, and where nothing workable exists the client may end the affected services with no penalty for the unexpired term.

What does not happen. Personal data is not sold, rented or traded, and reaches no data broker, advertising network or list vendor. Disclosure to law enforcement, a court or a regulator happens only where the law compels it, and we tell the affected client or individual wherever we are permitted to.

The position

Some of our providers operate outside the United Kingdom. A content delivery network serves from whichever edge sits nearest, by design, and several of the largest platforms keep their head offices in the United States. Where personal data crosses the border we rely on one of four mechanisms, and international transfers are never left to chance.

What this means in practice

Where the transfer agreement or the addendum is the mechanism, a transfer risk assessment is completed first. It covers the destination's law on state access, how sensitive the material is, the recipient's own safeguards and its record of transparency, and whether supplementary measures — encryption on the wire and in storage, keys retained on our side, pseudonymisation, or simply reducing which fields travel — bring the risk down to something acceptable. Where they do not, the transfer does not happen.

In the instructed chair we move client material out of the United Kingdom only on documented instruction, and we tell clients at scoping which providers involve a border crossing so that they can assess it as the deciding party. Where a client needs processing confined to the UK or the EEA, we say honestly before signature whether our stack can deliver that.

The position

Where the law fixes a period we follow it. Where the period is our judgement, the reason is printed beside it, because a retention schedule without reasons is a list of numbers nobody can challenge.

What this means in practice

Deletion is not instantaneous, and it would be misleading to imply otherwise. Material removed from a live system persists in encrypted backups until those rotate, which takes at most 30 days, and a restored backup is re-cleansed of anything that had been deleted before the restore.

The position

The law asks for measures proportionate to the risk rather than measures that sound impressive. What follows is what we actually operate, which is why it reads as a list of habits rather than a list of adjectives.

What this means in practice

Technical measures

• Encryption. Every connection to this site, to our application back-ends and to the systems we operate runs over TLS 1.2 or above, with strict transport security enabled here. Databases, object storage and backups carry provider-managed encryption at rest, and local working copies live only on devices with full-disk encryption.
• Access control. Named individual accounts, never a shared login; a second authentication factor wherever an account will take one — mail, hosting, source control and the store consoles included; access granted per engagement and surrendered at handover; and a periodic review of who still holds what.
• Credential handling. Client credentials live in a password manager and never in mail, documents, code or chat. System secrets live in the platform's secret store and never in source control. Anything exposed is rotated immediately.
• Segregation. Each client sits in its own environment or its own logically separated store. Client material is not pooled.
• Logging. Authentication and administrative actions are logged in the systems we operate, held for a defined period and kept out of any analytics pipeline. Availability and error monitoring runs where we operate a system.
• Backups. Automated, encrypted, on the cycle at Item 19, with restores tested rather than assumed to work.
• Endpoints. Supported operating systems, automatic updates, full-disk encryption, screen lock and remote wipe.
• Secure development. Version control with reviewed changes; dependency tracking with advisories acted on out of cycle; input validation, parameterised queries and output encoding as standard practice; secret scanning before anything is pushed; and production access held separately from development access.

Organisational measures

• A written confidentiality obligation binds everyone with access to personal data and survives the end of their relationship with us, and people work to what their task needs rather than to what they could reach.
• Supplier diligence is completed before a provider receives anything: security posture, where material sits, sub-processing, breach notification, and destruction on termination.
• Privacy questions are asked at design stage rather than retrofitted. Where a build looks likely to carry high risk we tell the client an impact assessment is needed and help carry it out.
• Incident response follows a documented route from detection through containment, assessment and notification to review, as Item 21 describes.
• Every engagement ends with a clean handover: our access revoked, credentials rotated by the client, and our working copies destroyed.

No arrangement of controls makes a system perfectly secure, and we would not claim otherwise. These measures are proportionate to what we hold, and they are reviewed as our work changes.

The position

A personal data breach is any failure of security that destroys, loses or alters personal data, or exposes it to somebody who should not have reached it, whether or not anyone acted deliberately. A mislaid laptop qualifies. So does an attachment sent to the wrong recipient. Treating only dramatic events as breaches is how organisations miss the ones that matter.

What this means in practice

Internally the sequence is fixed. Anyone who suspects a breach reports it to the director the same day, without waiting to be certain. We contain it — revoking access, rotating credentials, isolating the system, recalling what can still be recalled. We then assess what was involved: whose material, how much, how sensitive, whether it was encrypted, and what harm could realistically follow. Every breach is recorded whether or not it is reportable, with the facts, the effects and the remedial action, and once it is closed we change the control that let it happen.

In the deciding chair. Where a breach looks likely to place the rights and freedoms of individuals in jeopardy, the ICO hears from us inside 72 hours of our becoming aware, in stages and with reasons where the full picture has yet to be assembled. Where those individuals face a high risk, they hear from us without undue delay and in plain words: what happened, what was involved, what we are doing, what they should do, and who to speak to. That notice will not be buried in a release note.

In the instructed chair. Where a breach touches material we handle for a client, we notify that client without undue delay after becoming aware and inside the timescale in the processing agreement. The client decides whether the regulator and the individuals are told; we supply what they need to make that decision and to give that notice, and we help with containment and remediation. We do not notify on a client's behalf unless instructed to.

The position

The rights below are exercisable against us where we hold the deciding chair. Where we are instructed by a client, the request belongs with that organisation and Item 12 sets out what we do if it reaches us first. Our duty to assist them is real and we act on it promptly.

What this means in practice

Making a request. Write to enquiries@therevenuehouse.uk or to the address at Item 02. Particular wording is not required and citing the legislation is not required, though naming the right you want and the material you mean will get you a better answer sooner. There is normally nothing to pay. We do have to be reasonably satisfied that you are who you say, since handing your file to an impersonator would itself be a breach; a reply from the address we already hold for you usually settles it, and where it does not we ask for proportionate evidence, explain why we need it, and destroy that evidence once you are verified.

Timescales. We answer inside a month of your request, or of receiving whatever we need to identify you. A complex or repeated request can stretch that by as much as two further months, and where it does we say so before the first month is out and give you the reason. Where we decide not to act, we say why and point you to the regulator and to the courts. A request can be refused, or a reasonable charge applied, only where it is manifestly unfounded or excessive, and the burden of demonstrating that sits with us and not with you.

The position

Complaining about our handling of your personal data, or of your request, is your entitlement and the UK supervisory authority exists to hear it, and nothing in this memorandum delays or conditions that. We would rather hear it first, because most of what goes wrong is fixable once somebody points at it, but you are under no obligation to come to us before going to the regulator.

What this means in practice

Raise it with us at enquiries@therevenuehouse.uk, saying what went wrong and what you would like done about it. We investigate and reply in writing. Separately or instead, the regulator can be reached at:

Information Commissioner's Office — the United Kingdom's supervisory authority for data protection.
Postal address: Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF.
Telephone 0303 123 1113 · ico.org.uk

You are also entitled to an effective remedy through the courts against a controller or a processor, and to compensation where an infringement has caused you damage.

The position

Capacity: controller, for applications published under our own name on the App Store and Google Play. This item is the baseline for all of them; where an individual application collects something beyond it, that appears in the application's own notice and its store declarations are written to match. Where an application is built for a client and published under the client's account, the client takes the deciding chair.

What this means in practice

Permissions are requested where they make sense — as you reach for the feature, instead of in a queue of prompts at first launch. Every one can be declined and later withdrawn, and declining never disables the product as a whole.

On the device or on a server. What you create is written to the device first, so the product works with no connection, and it stays there unless you switch on sync or use a feature that inherently needs a server — signing in on a second device, sharing with a colleague, or pulling figures from a connected system. With sync on, content travels over TLS and rests on our hosting provider's infrastructure, encrypted at rest, in a UK or EEA region wherever the provider offers one. Switching sync off stops further uploads; closing the account removes what was uploaded, as Item 25 describes. Anything held only on your device goes when the app is deleted, and it cannot be recovered by us.

Failure reports and counters. What a failure report carries is the stack trace, the exception raised, the product's state at the moment it stopped, and the application, operating system and device versions. It does not carry your entries, records, values or attachments, and our crash tooling is configured to keep user content out of log lines. Where a product includes usage counters, those are tallies of a screen being opened or an export being run, with no free text and no field values; where recording them means storing or reading anything on your device beyond what is strictly necessary, we ask inside the product first, as PECR requires, and the choice is changeable at any point in the privacy settings. Declining costs you no feature. The platform-level analytics settings offered by Apple and Google remain entirely yours to control.

Identifiers. Our products use a random per-installation reference for grouping failure reports and for support. It resets when the application is reinstalled and is linked to no other identifier. The iOS Identifier for Advertisers and the Android Advertising ID are not read, devices are not fingerprinted, and no stable identity is derived from device characteristics.

App Tracking Transparency, privacy labels and Data Safety. Tracking, on Apple's definition, means joining what our product collects to third-party data for advertising or measurement purposes, or handing it to a broker of such data. Our products do neither, so they carry no tracking, never touch the advertising identifier, and present no App Tracking Transparency prompt; the absence of that prompt is a design decision and not an omission. Were a product of ours ever to track in the sense Apple means, we would request permission through App Tracking Transparency first, honour a refusal, and update this memorandum and the privacy labels before the release shipped. For each product we complete Apple's privacy labels and Google Play's Data Safety declaration, and we commit that those declarations match this memorandum — the same categories, the same purposes, the same sharing and the same deletion routes. Where a store form forces a coarser category than the truth, we select the more conservative option and explain the detail here. Our Data Safety declaration records that data travels encrypted and that erasure may be requested, and the account-deletion address Google insists on points at Item 25.

The position

You can delete your account without asking anyone's permission, without explaining why, and without losing access to the route because your device broke. Two paths exist and they reach the same outcome.

What this means in practice

Inside the product, at Settings › Account › Delete account, which is the in-product path both stores require and which is present in every application of ours carrying accounts. Or by writing to enquiries@therevenuehouse.uk putting the words Account deletion request into the subject line, writing from the address the account is registered to — a route that still works when the device does not.

Deletion finishes within 30 days of a request we have verified, and usually a good deal sooner. It removes the account record, synced content, device and push tokens, the history of feature counters and support correspondence linked to the account. Backup copies clear as backups rotate, inside the 30-day cycle at Item 19. A short list of records outlives the account, and each has a stated reason:

One warning worth stating twice: closing your account with us does not stop a subscription billed by a store. That has to be cancelled in the store's own subscription settings, or renewal charges will continue arriving.

The position

We operate no newsletter, run no campaign list, and buy or rent no marketing data. What arrives from us is either a reply to something you sent or a message about an engagement, an account or a service you already have.

What this means in practice

Should a mailing list ever be introduced, four commitments apply and this item will be rewritten before the first message is sent. You would be added only where you had opted in, or where you are an existing client and the message concerns similar services under the soft opt-in in PECR regulation 22(3) — never because a business card once reached us. Every message would carry a working single-click unsubscribe, honoured at once and permanently. Your details would go to nobody else for their own marketing. And you could tell us at any moment to send nothing beyond what an active engagement requires.

The position

This memorandum is reviewed at least once a year, and additionally whenever something changes that affects personal data — a new provider, a new application feature, a new category of material, or a new route by which data crosses the border. The version in force always sits at this address with its number and date at the top.

What this means in practice

For a minor change — a clarification, a corrected phrase, a provider that has renamed itself — we amend the page and move the date. For a material change — a new purpose, a new category, a new recipient, a new lawful basis, or a new border crossing — we give advance notice by email to account holders and current clients, and by notice inside the product where application users are affected, normally at least 30 days before it takes effect. Where a change needs your consent we ask for it rather than assume it. Where we hold the instructed chair, changes of sub-processor follow Item 17 and the processing agreement governs.

Version record. Version 1.0, 31 July 2026, first publication. Version 2.0, 5 August 2026, adding the split between our two capacities, the inventories with lawful bases, the recorded balancing exercise, the consulting-specific items, the sub-processor and transfer detail, the itemised retention schedule and the expanded security, breach, rights and application items. Version 3.0, 15 August 2026, restructuring the whole document as a numbered memorandum, rewriting every item in that form, and stating for each one the action owed to the reader.