Effective 14 August 2026Register revision 2.0WORKFLOW AI SOLUTIONS LTDCompany number 17005372
01 Who keeps this register
WORKFLOW AI SOLUTIONS LTD maps a repetitive business process, writes the specification for it, builds the automation inside a client's own accounts and then hands the whole thing over. This notice describes the personal data that moves while that work happens, and the personal data that arrives for a much smaller reason: somebody wrote to the practice, or somebody loaded a page on this website.
The practice is a private limited company in England and Wales carrying company number 17005372. Where this notice says we, it means that company. Where it says you, it means the identifiable person the data describes, whether you are an enquirer, a named contact at a client or supplier, or a visitor whose request this site answered.
One mailbox handles every matter raised by this notice, from a straightforward question to a formal demand under the UK GDPR: hello@wfaisolutions.co.uk. Letters reach us at the office filed against company number 17005372 at Companies House. Data protection questions are handled by the director rather than routed to a help desk, and the practice falls outside the three categories in Article 37 of the UK GDPR that oblige an organisation to appoint a Data Protection Officer. Because the practice offers its services in the United Kingdom, no representative under Article 27 is appointed either. Should either fact change, the revision log in section 17 will record it.
A workflow specification written by this practice records five things about every step, and this notice is laid out the same way. If the format looks unusual for a privacy notice, that is deliberate: a policy that cannot be read as a map of what actually happens is a policy nobody can check us against.
Key to the five fields used throughout this notice
Field
What it records
Trigger
The event that starts the activity. Nothing in this register runs without one.
Inputs
The categories of personal data that enter at that trigger, and nothing beyond them.
Steps
What the practice performs on those inputs, in the order it happens.
Outputs
What the activity produces and who ends up holding it.
Controls
The lawful ground, the boundary on reuse, and the rule that eventually disposes of the record.
Data protection law asks a threshold question before anything else: who decided that this processing would happen at all. The organisation that decides is a controller. An organisation that only executes another's documented decision is a processor. This practice occupies both positions, on different data, and the boundary between them is the most useful thing in this notice.
3.1 The register we own
Role: controller
Correspondence with the practice, the paperwork of an engagement, the supplier and accounting trail, and the request log produced by this website all belong to us. We chose why each of those activities exists. Sections 4, 5 and 9 through 17 map that register, and every activity in it carries the controller flag above.
3.2 The register a client owns
Role: processor
An automated workflow built by this practice usually moves personal data about a client's customers, staff or suppliers. That data was never ours to decide about. The client is its controller and we act on the client's written instruction under a contract meeting Article 28 of the UK GDPR. Section 6 maps what that looks like in practice.
3.3 Why the boundary decides who you write to
If an automation we built touched data about you, the organisation that runs the automation is the one holding your rights, not us. Write to it. A request that lands here instead will get a straight answer naming the controller wherever we can identify it, an offer to pass the request along, and confirmation once it has gone. What we will not do is act on another organisation's data because the request sounded urgent.
Four activities. Each is mapped below in the five fields set out in section 2. There is no fifth activity hiding behind a phrase such as business purposes.
4.1 Enquiry correspondence
Trigger. A message arrives in the practice mailbox, either typed straight into your own email client or composed by the enquiry form on this site, which hands the finished message to that client for you to send yourself.
Inputs. Your name as you sign it, the reply address in the message header, the organisation you say you work for, and whatever description of a process you decided to write. Correspondence about a live workflow may also carry system names, ticket volumes and the odd screenshot.
Steps. The message is read, answered, and kept in the mail account as the thread of that conversation. Where an enquiry turns into an engagement, the thread moves into the engagement file described at 4.2.
Outputs. A reply to you, and a stored thread visible only to the practice.
Controls. Legitimate interests, or steps taken before entering a contract where you asked for a quotation. Nothing from an enquiry is added to a marketing list, because the practice runs none. Disposal rule at section 9.
4.2 The engagement file
Trigger. A signed proposal or an accepted quotation for a process review, a specification or a build.
Inputs. Names, job titles, work email addresses and work telephone numbers of the people we deal with at the client; the notes taken while mapping how the process is really performed; and the credentials issued to us, which are held only as instructions for where to authenticate, never copied into a document.
Steps. Notes are written up into the process map and the specification. Meetings are scheduled. Progress is reported. Invoices are raised against the agreed stages.
Outputs. The documents the client bought, the running workflow inside the client's accounts, and an accounting record on our side.
Controls. Performance of the contract for the individuals who are party to it; legitimate interests for the colleagues of theirs who appear in a process map; legal obligation for anything the tax and companies legislation makes us keep.
4.3 Supplier and finance trail
Trigger. A subscription renews, a contractor invoices us, or the accounting period closes.
Inputs. Contact names at suppliers, payment references, invoices in both directions and the correspondence attached to them.
Steps. Recorded in the bookkeeping system, reconciled, filed and produced to the accountant preparing the statutory accounts and returns.
Outputs. A ledger, a set of accounts, and the filings the law expects from a company.
Controls. Legal obligation for the records themselves; contract for the supplier relationship. The finance trail is never used to work out anything about a person, only about a payment.
4.4 The request log behind this website
Trigger. Your browser requests a page or a file from this domain.
Inputs. What any web server sees at the moment of a request: the internet address the request came from, the time, the path requested, the response code, the user agent string your browser volunteers, and a referring page if one was sent.
Steps. The hosting platform in front of this site records the request, uses it to serve the page, and keeps a short-lived aggregate so that abuse and outages can be seen. The practice does not query that log to build a picture of an individual visitor, and no identifier is written into your device to link one visit to the next.
Outputs. A served page, and a log entry that ages out on the platform's own cycle.
Controls. Legitimate interests in keeping a website available and defended. No analytics product is installed, so there is no visitor profile in existence to disclose, export or delete. The cookie position is set out in the cookie notice.
Article 6 of the UK GDPR insists that every activity carries a ground before it starts, not one chosen afterwards to justify what was done. The four grounds this register uses are set out below with the reasoning attached.
5.1 Performance of a contract, Article 6(1)(b)
Where you are the individual who engaged the practice, delivering what was agreed requires processing your details. The same ground covers the steps you ask for before signing, such as scoping and quoting a process review.
5.2 Compliance with a legal obligation, Article 6(1)(c)
Invoices, ledgers, the trail behind a set of accounts and anything a tax authority may later ask to see are kept because statute requires a company to keep them. Consent has no role here; the obligation stands whether or not anybody would prefer the record gone.
5.3 Legitimate interests, Article 6(1)(f)
This ground carries the enquiry mailbox, the colleagues named in a process map, the defence of a legal claim and the request log behind the site. Article 6(1)(f) only works after a balance has been struck, so here is ours in plain terms. The interest is running a consultancy that answers its post, documents its work accurately and keeps its website standing. The processing is limited to business contact details and the description of a working process, so the intrusion is slight and lands on people in their professional capacity. Nobody is surprised to find their work address in the mailbox of a firm they wrote to. Where the balance ever tips the other way, the objection route in section 11 stops the activity, and you can ask for the reasoning behind the balance in writing.
5.4 Consent, Article 6(1)(a)
Consent appears in this register only where a client asks us to hold a named individual's contact details beyond the end of an engagement for a reason of their own. It is recorded when taken, it is never bundled into a contract, and withdrawing it is as easy as one line of email.
5.5 Special category data
Nothing in the four mapped activities calls for the categories protected by Article 9 of the UK GDPR, such as health or biometric data. Where a client's workflow carries such data, it stays in the client's register, under the client's Article 9 condition, and section 6.2 explains the boundary that keeps it there.
Before a build starts, the client and the practice sign a data processing agreement carrying the terms Article 28 of the UK GDPR requires: subject matter, duration, the nature and purpose of the processing, the categories of data and of people involved, and the client's power to instruct. The specification produced at step two of the method is the operational half of that instruction, because it names every step at which personal data is read, written or passed on. Anything not written into those two documents is not something we are entitled to do.
6.2 The boundary that does not move
Client data is worked on for the client's stated purpose and no other. It is not pooled with another client's data. It does not become training material for any model, ours or a supplier's, and where a model interface is used inside a workflow, the account and its settings belong to the client, so the position on training is theirs to set and ours to respect. It is not mined for statistics we could publish, and it is never sold, rented or exchanged. Where a workflow needs test data, we ask for a masked extract or generate a synthetic set rather than take a copy of the real thing.
6.3 The narrow window in which we hold anything
Most of the time nothing lands on our side at all, because the automation executes inside the client's accounts against the client's systems. Three exceptions exist and each is time-boxed. A sample of real records may be needed to prove that a parsing step handles the awkward cases, and it is deleted once the acceptance test passes. A failure sometimes has to be reproduced from a log line that contains a record identifier, and the extract goes when the fix ships. The comparison report from the parallel run may quote individual records to show where automated and manual output disagreed, and it is handed to the client and removed from our side at handover.
6.4 Standing by the client
As processor we assist the client with the duties the UK GDPR places on it: responding to a person exercising rights against the client, assessing the impact of a proposed workflow before it goes live, and reporting an incident up the chain without delay. Every sub-processor in the path is disclosed in advance and listed in section 7. When the engagement ends the client chooses whether the working copies are deleted or returned, and section 12 records what that instruction sets in motion.
A short supplier list is a design decision, not an accident. Every organisation with a possible line of sight to personal data handled by the practice appears below, with the reason it is there.
Suppliers with a line of sight to personal data
Supplier
Why it is in the path
Data it can reach
Where it processes
Business email and document provider
Carries and stores the correspondence of the practice
Everything written to or by the mailbox, plus engagement documents
United Kingdom and European Union data regions, with support access possible from elsewhere
Hosting and content delivery platform
Serves this website and absorbs abusive traffic
Request log entries as mapped at 4.4
A global edge network, with the nearest location answering your request
Accounting software and the practice accountant
Bookkeeping and the statutory filings of a company
Invoices, payment references and supplier contacts
United Kingdom
Named contractor, only when disclosed first
A specialist skill a build needs and the practice does not carry
Whatever that single piece of work requires, bounded in writing
United Kingdom unless the client agrees otherwise in advance
Scroll the table sideways to read every column
Two categories of supplier are deliberately absent from the path. The first is any advertising, tracking or audience measurement service, since none is installed on this site. The second is any product to which the practice would have to upload a client's records in order to work on them; where a workflow needs a service of that kind, it runs in the client's own account under the client's own contract, and the supplier answers to the client instead of to us.
Work is done from the United Kingdom and the practice prefers suppliers who will keep data in the United Kingdom or the European Economic Area. Two realities complicate that preference: an edge network answers a request from wherever the visitor happens to be, and a support engineer at a large software vendor may sit in another country. Both are treated as restricted transfers and neither is left to chance.
8.2 The three mechanisms available
Adequacy. Where the receiving country is covered by United Kingdom adequacy regulations, the transfer stands on those regulations and needs nothing further from us.
The International Data Transfer Agreement. For a supplier outside adequacy, the practice signs the IDTA published by the Information Commissioner, or the Addendum that bolts the same protection onto the European Commission's standard clauses where a supplier already offers those.
A transfer risk assessment. Before either instrument is relied on, the destination is assessed for what the contract cannot fix, such as a public authority's power to compel disclosure. If the assessment cannot be satisfied, the supplier is not used for that data.
8.3 Where the instruction comes from a client
A client may instruct a workflow that sends data abroad, for example to a model interface hosted in another region. That decision belongs to the client as controller. Our duty is to say clearly what the specification would cause, before it is signed, and to build only what the client then instructs. Copies of the transfer paperwork we rely on are available to a client or to you on request to the mailbox in section 1.
Every activity in section 4 carries a disposal rule: a retention period, written as the event that starts the clock and the time that runs from it. A record is not kept on merely because clearing it out would be a nuisance, and the retention periods below are the ones actually applied.
Disposal rules by record type
Record
Disposal trigger
Period from that trigger
Why
Enquiry that went nowhere
Last message in the thread
12 months
Long enough to recognise a returning enquirer, short enough not to become an archive
Engagement documents and correspondence
Handover of the workflow
6 years
Matches the window in which a contract claim can still be brought
Invoices, ledgers and accounting records
Close of the financial year the record belongs to
6 years
Required of a company by tax and companies legislation
Working copies of client data
Acceptance test passed, fix shipped, or handover completed
30 days at the outside
The narrow window described at 6.3, closed as soon as its purpose ends
Website request log
The request itself
The hosting platform's own short cycle
Availability and abuse handling need days, not history
A record under legal hold
Resolution of the dispute or claim
Held until then, then disposed of under the row above it
Deleting evidence while a claim is live is not an option available to anyone
Scroll the table sideways to read every column
Disposal means deletion from the live system, after which the copy inside a backup set expires on that system's own rotation rather than being surgically removed. Until it expires, that copy is restored only as part of a whole-system recovery, never queried on its own.
Article 32 of the UK GDPR asks for security proportionate to the risk. Listed below are the controls actually in place, in the order they bite.
Access begins at zero. Credentials for a client system are issued by that client, scoped to the one workflow we deliver, and revoked by the client at handover. The practice asks for the narrowest scope that will do the job and says so if a client offers more.
Every account carries a second factor. That applies to the mail account, the accounting system, source control and every client system we are admitted to.
Secrets stay out of documents. Keys and tokens live in the secret store of the platform running the workflow. A specification names where a credential is fetched from; it never contains the credential.
Devices are encrypted and patched. Full disk encryption and current operating system updates on every machine used for the work.
Transport is encrypted. This site is served only over HTTPS and declares a strict transport policy; interfaces we build against are called over TLS.
Logs are designed to be readable without being revealing. A workflow logs identifiers and outcomes so a failure can be traced, not whole payloads of personal data, and a client can read the log without asking us what a line means.
The blast radius is bounded. Because the automation runs in the client's accounts rather than on a shared platform of ours, an incident at this practice cannot reach a client's production data through us.
No control set removes risk entirely, and this notice will not pretend otherwise. What the practice commits to is the exception path in section 15 when a control fails.
Send one email to hello@wfaisolutions.co.uk saying what you want. There is no form to complete, no portal to register with and no charge, unless a request is repetitive to the point of being manifestly excessive, in which case the UK GDPR allows a reasonable fee and we would tell you the figure before doing the work rather than after. Post to the registered office works equally well and simply takes longer to arrive.
11.2 Proving the request is yours
Handing your data to somebody claiming to be you would be its own breach, so identity is checked in proportion to what is being asked for. Writing from an address already in the correspondence is usually enough. Where it is not, we will ask one targeted question rather than demand a passport scan, and any document sent for identification is deleted as soon as the check is done.
11.3 Clock and outcome
The statutory period is one calendar month from the day the request is received and understood, extendable by two further months for a request that is genuinely complex, in which case the extension and the reason for it are sent inside the first month. Every reply names the outcome. Where a right is refused, the reply gives the exemption relied on and the route in section 16 for challenging that.
11.4 The rights themselves
Access, Article 15. A copy of the personal data held about you, together with the purposes, the recipients, the disposal rule and the source. Where a document is mostly about somebody else, the parts about them are redacted rather than the whole document withheld.
Rectification, Article 16. Correction of an inaccuracy, and completion of a record that is misleading because something is missing. Anyone we passed the wrong version to gets the correction as well, unless that proves impossible.
Erasure, Article 17. Deletion where the data is no longer needed, where consent was the ground and has been withdrawn, or where an objection succeeds. Section 12 covers what survives erasure and why.
Restriction, Article 18. Processing paused while an accuracy dispute or an objection is worked through. The record stays but sits untouched.
Portability, Article 20. Data you supplied under consent or contract, returned in a machine-readable form another provider can ingest, or sent straight to that provider where the transfer is technically feasible.
Objection, Article 21. A challenge to any activity resting on legitimate interests. The activity stops unless we can show grounds that override your interests, and we would put those grounds in writing rather than assert them.
Rights around automated decisions, Article 22. The position is set out in section 13, because it is a design commitment rather than a paragraph of law.
Withdrawal of consent. Where consent was the ground, it can be withdrawn at any time. Withdrawal is not retrospective, so it stops the processing without unpicking what was lawfully done before.
Ask us to delete your data, writing from the address the correspondence already runs through, and the thread with any contact record built from it goes out of the live mail and document systems. Confirmation comes back naming what went and what stayed. What stays is invoicing and accounting material, kept under the legal obligation in section 5.2, and anything sitting under a live legal hold. That residue is not used for any further purpose; it sits in the ledger.
12.2 Deleting data a client controls
If your data reached us inside a client's workflow, the deletion decision is the client's to make. Their instruction reaches us, we execute it against the working copies described at 6.3, and we confirm to the client what was removed. The automation itself lives in the client's accounts, so deleting records inside those systems is something the client performs directly, and the runbook handed over at the end of an engagement explains how.
12.3 What handover triggers
Handover is the disposal trigger with the widest effect. Access we were granted is revoked by the client. Working copies of client data are destroyed within the window in section 9. Credentials, runbook, architecture notes and the recorded walkthrough are already inside the client's accounts, because they were never held anywhere else. What remains on our side is the engagement correspondence and the accounting trail, on the periods that table sets.
The practice takes no automated decision about any individual. Nobody is scored, ranked, credit-checked, screened or profiled here, and no decision producing a legal or similarly significant effect on a person is reached inside our own register. That is the Article 22 position, and it is short because it is absolute.
Workflows built for clients are a different question, and the answer is a design rule rather than a disclaimer. Where a step can be done by an ordinary rule, a rule is written, because a rule can be read, tested and explained. A language model is used only where a step genuinely calls for reading and judgement, such as classifying free text, pulling fields out of documents that arrive in a dozen shapes, or drafting a reply that a person then approves.
Where the outcome would matter to a person, the specification puts a human decision-maker in the path and names them. The automation prepares, a person commits. We argue for more approval points than most clients expect and set out what each one costs in elapsed time. Where a client wants a decision with a significant effect taken with nobody in the path, that is work this practice declines, and it says so at the specification step rather than after the build.
This is a business-to-business practice. The website explains a professional service, the enquiry route is aimed at people acting for an organisation, and nothing here is designed to appeal to or attract a child. The practice does not knowingly collect data about anyone under 18 into its own register, and no service is offered directly to a child in the sense of Article 8 of the UK GDPR.
Should a child's details reach the mailbox anyway, the record is deleted once it is noticed, with no attempt to work out who sent it. Anyone who believes a child's data has arrived here should write to the mailbox in section 1 and it will be dealt with the same day it is read.
Client workflows can legitimately involve data about children, in a school administration process or a family services case load. Where that is on the table, the age of the people in the data is stated in the specification, the client's own protective measures are written into the design, and the client remains the controller answering for them.
Every mapped process needs an exception path, and this is the one that matters most. It is written down in advance because the middle of an incident is a poor moment to invent a procedure.
Trigger. Any sign that personal data has been exposed, altered, lost or reached somebody who should not have it, whether spotted by us, reported by a client or flagged by a supplier.
Contain first. Revoke the credential, close the route, stop the workflow. Containment comes before the paperwork, always.
Establish the shape of it. What data, whose data, how much, over what period, and whether it can still be reached. The timeline is written as it is discovered rather than reconstructed later.
Where the data is ours to answer for. If the exposure could realistically cause harm to the people involved, the Information Commissioner is notified inside 72 hours of the practice becoming aware, and where the risk to those people is high they are told directly, in language that says what happened and what to do about it.
Where the data belongs to a client. The client is told without undue delay and given what its own notification duty requires, which means facts rather than reassurance. The client decides what goes to the regulator and to the people affected, because the client is the controller.
Close the path. Every incident produces a written note of cause, effect and the change made so the same route cannot open twice. Clients affected receive that note.
Notifying late is worse than notifying with gaps, so a first notification is sent on the facts then established and updated as more becomes known.
Complaining to the practice first is welcome and usually quicker, but it is not a step you are obliged to take. The statutory route stands open whether or not you have raised anything with us.
The supervisory authority for the United Kingdom is the Information Commissioner's Office, the ICO, reachable at Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, on 0303 123 1113, and through the complaints pages of its own website. Its remit covers this practice as a controller, and it can look at how any part of this register operates.
Nothing in this notice affects the separate right under Article 79 of the UK GDPR to bring proceedings in court, or the right to compensation under Article 82 where processing that breaks the rules has caused damage.
This notice is versioned like a specification. The revision number and effective date sit at the top of the page, and a change to what is actually done here produces a new revision before the change goes live, not afterwards.
Where a revision materially alters how personal data is handled, clients and correspondents on live matters are told by email. Editorial tidying of wording is made without an announcement. Superseded revisions are kept and sent to anyone who asks the mailbox for the version that applied on a particular date.
The document controlling any question about the practice's own processing is this one, at the revision shown at the top of the page. Where a signed data processing agreement with a client says something different about that client's data, the agreement wins.