Checking a finance-content vendor's authority, data chain and exit before signing

An England-based publisher receives a proposal from a finance-content supplier and is preparing to commission research and production. The supplier presents its authority, information handling and continuing support as settled. Rather than score the pitch, the publisher opens an evidence file and follows the decision from proposal to a hold on signature, using the selection checks.

A proposal becomes a commissioning decision

The publisher pauses signature because the offer has not established who is responsible, what the supplier is authorised to do, where information travels or whether the work can be recovered after exit.

The case is fictional, and missing records are treated as an evidence gap rather than proof that the supplier has failed. The file is not a certificate and does not replace financial-regulatory, privacy, cyber-security or contract advice. A polished proposal cannot resolve an unanswered question by itself.

The supplier name does not settle responsibility

The first finding is that the offer and supporting documents do not yet make the legal entity and delivery responsibilities clear enough to approve. The publisher compares the proposal, terms, privacy notice, invoice and insurance evidence before deciding who it would contract with.

It also asks which organisations host the service, support users or receive personal information, including any reseller or subcontractor. The publisher needs the named signatory and payment recipient to match the entity taking responsibility, rather than assuming that a trading name identifies every party in the delivery chain.

The FCA Firm Checker and Companies House comparison helps explain what the public company information service can show, including officers, filings and previous names. Companies House guidance and the register are starting points, not proof that submitted information has been verified or that one organisation is responsible for every part of delivery.

A claim of expertise meets a permission check

The publisher asks the supplier to describe the service in plain language, separating factual research, legal advice, regulatory approval, data processing and software support. Named qualifications and insurance also need evidence checked with the responsible body, rather than a general assurance of competence.

If the supplier claims FCA status, the publisher checks the legal entity, reference number, permissions, restrictions and contact details against the current Financial Services Register. The permission check helps distinguish expertise from permission. The register is not an endorsement, and the reviewer checks whether the precise entity can approve the relevant financial promotions.

The file cites the FCA's pages on using firms authorised or registered by the FCA and on approving financial promotions. The finding is not that the supplier lacks authority; the claim has not yet been evidenced against the task. The publisher asks for clarification before treating a claimed permission as a reason to sign.

The information route is still unfinished

Before onboarding, the publisher lists each data field, its purpose and who can see it. It records whether each party acts as a controller, joint controller or processor for that purpose, and uses the data chain to identify subprocessors, hosting countries, remote-access locations, retention and deletion arrangements.

In this case, the route is not clear enough to approve. The publisher asks where information goes during normal operation, support, backup and incident response. It also records any restricted international transfer and its proposed safeguard, using the international transfers guide to inform the review rather than relying on the provider's headquarters alone.

The governing law is the UK GDPR together with the Data Protection Act 2018. Article 28 of the UK GDPR requires a written contract with any processor, and Chapter V governs restricted transfers. Where the file shows personal data leaving the UK, the publisher asks which mechanism is relied on: an adequacy decision or UK regulations, the ICO's International Data Transfer Agreement, or the UK Addendum to the EU standard contractual clauses. A transfer risk assessment goes with the last two.

The case also touches creators. If the vendor will write scripts or briefs that creators publish, the publisher adds two questions. Who approves each piece as a financial promotion before a creator posts it? And may the vendor reuse a creator's name, image or audience data after the engagement ends?

A dry run reveals the handover gap

The security review remains incomplete because claims about controls have not been matched to evidence or a working incident route. The publisher requests information about multi-factor authentication, role controls, encryption, logging, backups, vulnerability handling and breach notification.

It checks the scope and date of any independent assurance, asks how privileged support access and departed staff are handled, and records an incident contact. A harmless scenario tests the escalation route. This reveals what the file still needs to show, without treating a missing record as proof of a security failure.

The NCSC supply-chain principles help organise checks around understanding risk, establishing control, checking arrangements and improving them. The publisher applies them proportionately, not according to contract value alone, and records the cloud security principles and ICO security guidance as possible follow-up references.

The agreement must define the service, evidence standard, turnaround, change process, accessibility, confidentiality and correction support. The contract terms should state ownership and permitted reuse of drafts, datasets, prompts, calculations and review notes, so responsibilities are clear during delivery as well as at signature.

For processor work, the contract covers instructions, security, subprocessors, rights requests, audits and return or deletion. The ICO page on contracts and liabilities between controllers and processors is under review following the Data (Use and Access) Act, so the publisher rechecks it and seeks qualified privacy review before settling the wording.

The handover cannot yet be rehearsed

The final finding is that the supplier has not shown a usable export, so the publisher does not onboard it. The agreement needs to set notice, transition help, export formats, backup deletion and a response if the provider fails, rather than leaving recovery to an informal promise.

The service standards and the handover process inform the evidence expected for service and transfer. The publisher keeps signature on hold until the export can be understood and the unresolved responsibilities have been answered in the file.

An exit plan the publisher could accept names the formats and tests them. Illustratively, datasets and audience lists come in CSV or JSON, drafts and scripts in DOCX or plain text, and approval records and audit logs as PDF or CSV with dates. The publisher asks for a sample export in week one, restores it into a blank workspace and checks that record counts and approval dates match. It also asks for written confirmation of backup deletion within a stated number of days of termination. A plan with no tested sample stays a promise.

What the publisher carries into future purchases

The decision is to keep authority, information handling and continuity as separate checks. A public record can establish what that record shows, but it cannot establish endorsement or prove that a supplier will meet every contractual requirement.

For a later review, the publisher records the legal entity and matches it across the offer and supporting documents. It verifies the precise permission claimed, maps data fields and purposes, checks locations and deletion points, reviews security evidence and incident escalation, and contracts for delivery standards, ownership and a usable exit.

The file closes with pass, conditional pass or reject, and gives each condition an owner and due date. A missing record is not evidence of failure, but reassurance is not a substitute for evidence. If the entity, permission, information route or workable export remains unclear, the publisher keeps onboarding paused.