If you’re the person who has to sign off on bringing in an outside system to touch client data, you’ve probably been burned before by a vague answer to a direct question. So here is the direct answer, in the same words we use in contracting — not softened for a blog post and not expanded either.

01. What we actually collect

For an engagement, we hold two things: the source material and data the specific workflow needs, and the outputs it produces. Nothing more. We do not collect data a workflow doesn’t need on the theory that it might be useful later, and we do not repurpose engagement data for a second purpose once it’s in our hands. For an enquiry before any contract exists, we hold what you sent us — nothing is pulled from your systems before there’s a signed scope defining what for.

This is the same commitment stated on our Trust page, on the homepage, and in Pricing. We’ve made a point of using identical wording in all three places, because an IP or data position that changes depending on which page you’re reading is not really a position.

02. Who owns what

You own your data, your content, and the bespoke outputs built for you. Full stop, no asterisk. Rights in bespoke outputs are set out in your Statement of Work — either a non-exclusive licence or a full transfer, agreed before the build starts, not negotiated afterwards once you’re dependent on us.

What we keep is narrower than people expect: our frameworks, our methods, our reusable components, and the underlying architecture. These are the things we bring into every engagement — the accumulated method, not your specific data or your specific outputs. We couldn’t hand those over without taking them away from the next client we work with.

03. What we do with AI, specifically

This is usually the real question behind “how is our data handled” once AI is involved. Three commitments, stated plainly:

  • We do not use your data to train models — ours or anyone else’s.
  • AI assists at the drafting stage of a workflow. It never issues work to your client on its own. A qualified person reviews every draft against its evidence before anything goes out, and that review step is a design rule, not a configurable setting.
  • Where an AI provider processes data as part of a workflow, that processing is scoped, documented, and covered in your Statement of Work — not left to be discovered later in a support ticket.

The AI Transparency & Data Use Notice sets out the specifics for a live engagement. It’s written against a real system, not as a generic download, because a security overview written for nobody in particular describes nothing in particular.

04. How GDPR fits into a build, not just a policy

GDPR compliance for a workflow system isn’t a checkbox added after the build — it shapes the design. Two of the four layers we build (see what we build) exist specifically for this reason:

  • Access control. Who can see and do what is defined at design time and recorded, and it follows the role rather than the person — so access changes when responsibilities change, not when someone remembers to update a list.
  • Traceability. An audit trail runs from source material through approval to issued output: what was used, who approved it, when, and on which version. This is what lets a data protection officer answer a question about a specific piece of work months after it shipped, instead of reconstructing it from memory.

05. The exit path

Ending an engagement with us is a documented procedure. The handover pack, the documentation, and the exit path are given to you at acceptance — not assembled under pressure when a contract is ending. If you decide not to continue with Managed System Operations, you take the handover and run the system yourself. That’s stated on Pricing as a real option, not a formality.

06. Frequently asked questions

Does Motive Journey use our data to train AI models?

No. Your data is used only to operate the specific workflow it was provided for.

Who is the data controller for a Motive Journey engagement?

This is set out in the data processing terms attached to your specific contract, because it depends on the workflow and the systems involved — a generic answer here would be more misleading than useful. Ask during the fit call if your review needs this earlier than contracting.

Can we get security and data processing documentation before signing?

Yes. If your procurement or IT review needs it before contracting, raise it during the fit call and we’ll arrange it. We don’t publish it as a generic download because the version that matters is the one attached to your actual workflow.

What happens to our data if we end the engagement?

You receive the handover pack, full documentation, and a written exit path at acceptance. Ending the relationship afterwards follows that documented procedure.

If you’re preparing a review, the Trust page sets out how data and approval are controlled →