Yes, a company may be able to license its standard operating procedures, but owning a folder of instructions isn't the same as being free to offer it for AI training. SOP data licensing starts with three questions: who controls the words, what else is embedded in them and what use could your business authorise? None of that establishes buyer interest.
A procedure manual tells staff what should happen; training examples might also show how a task was handled when conditions changed. Those are different kinds of material, with different checks. ADP (Accord Data Partners) is an independent introducer, not a buyer or assessor of eligibility. It never receives company datasets, and an introduction doesn't mean a licence will follow.
Separate instructions from evidence of work
For SOP data licensing, separate the published rule from records showing its application. A clean set of instructions is one collection; task records showing where staff made a judgement are another. If you're considering the wider owner route, sell your company data explains introductions. It isn't a request to send ADP files.
A work instruction might say to pause an order when an address fails verification. A task record might show that the order was paused, checked and released after a correction. Decide whether you're describing instructions alone or a linked set of instructions and outcomes. Don't present a step-by-step policy as evidence that anyone followed it.
Hypothetical worked example: a repair firm has an approved equipment-check SOP and records showing how technicians closed particular checks. The firm lists the SOP as instructions and the closed checks as evidence of a completed workflow. It then asks whether the records can be described safely without disclosing customer details. The example is a sorting exercise, not a claim of buyer demand.
Check who wrote each procedure
An authorship record makes SOP data licensing easier to assess. For each procedure, note who drafted it, when they did so and whether they worked as an employee, contractor or external adviser. Start with the highest-use documents rather than trying to reconstruct every edit. A named file owner isn't necessarily the person who created its text.
Check the contract behind work commissioned from outside the business before assuming you can grant a copyright licence over it. GOV.UK's copyright guidance distinguishes permission to use a work from owning its rights. If an adviser wrote a section, establish what your agreement permits before including that section in a proposed collection.
SOP data licensing can involve documents assembled by several teams over many years. Mark passages with uncertain ownership for review instead of treating the whole document as either cleared or unusable. That gives you a practical choice: confirm the rights, remove the passage if the procedure still makes sense or leave that document outside the proposed scope.
Identify templates and third-party material
A third-party template can sit inside a procedure even after your staff have adapted it. Look for purchased checklists, supplier diagrams, software help text and material copied from a client's handbook. The question isn't just whether the finished SOP looks like yours. It's whether you have permission for the particular reuse you want to discuss.
Keep a simple note of document provenance: the original source, what your team added and any permission you can find. That note is more useful than a folder label saying 'internal'. If a supplier provided a safety sequence for use with its product, don't assume that permission also covers supplying the sequence for AI training.
For SOP data licensing, a clean selection of clearly owned material is more useful than a large folder with unexplained borrowed pages. Set aside uncertain items while you check them. You can still describe the kind of procedure involved without reproducing the disputed text or suggesting that your business controls rights it hasn't confirmed.
Keep versions and dates intelligible
Preserve a version history and an effective date for each procedure you may discuss. A file's last-modified timestamp might reflect a formatting change, not the date staff started using its instructions. Record what changed, who approved the change and which version applied during each period. That matters if related task records span a change in process.
SOP data licensing becomes harder to explain when a current manual is presented alongside older outcomes without a link between them. You don't need to make old and new instructions identical. You do need to say which rules were in force at the time, so a reader doesn't mistake a later correction for a step staff originally had.
Give enough operational context to explain a change without rebuilding the entire business system. For example, note that an approval step applied only to urgent repairs or that a checklist changed when equipment changed. If you can't establish why two versions differ, mark the gap. Guessing at a reason would make the collection less clear.
Explain exceptions without exposing secrets
Exceptions often explain more about a procedure than its routine path. An escalation rule might show when staff stop, seek approval or use another check. But the same page could reveal trade secrets, access controls or the precise circumstances in which a safeguard is bypassed. Identify what the exception teaches before deciding how much detail it needs.
For SOP data licensing, you might describe the decision in general terms while withholding exact thresholds, system names or security steps. That isn't a licence to rewrite events as if they happened differently. Keep a record of what was removed and why, then judge whether the remaining material still explains the task accurately.
Client obligations need a separate check. A client-specific exception may be confidential even when it contains no personal names, and a general licence from your own business can't override that commitment. If the exception cannot be explained without exposing a client's process, leave it out or seek the relevant permission before discussing its inclusion.
Describe the collection before sharing it
A sensible first step in SOP data licensing is an inventory, not a file transfer. Count the procedures, identify their subject areas and note which have linked task records, clear dates and reviewed rights. Separate current instructions from retired ones. This tells you what you could discuss without assuming every document in a shared drive belongs in the same offer.
Write a sample description rather than attaching a real example at the outset. You could describe a set as approved maintenance procedures from specified periods, with or without linked closure records, and explain what has been left out. Say whether diagrams, forms and exception notes are present. A description should make the collection understandable without disclosing its contents.
Maintain an exclusion list alongside that inventory. It might cover supplier pages with unclear rights, client-specific instructions or records that would take disproportionate work to separate. The list helps you estimate the actual preparation job and prevents an early conversation about a category of material from turning into an accidental promise to provide everything in it.
Consider what use you would allow
Before discussing SOP data licensing, decide what you would be willing to negotiate. Providing material to assess a possible licence is different from allowing it to be retained and used for AI training. Think about whether you could allow copies to be made, whether derived material may be kept and which parts of the collection must remain outside the deal.
A proposed permitted use should be specific enough for both sides to understand. Ask how the material would be accessed, whether it could be passed to others and what happens when the licence duration ends. Those questions aren't terms you must accept. They're a way to find out where your business's limits differ from a buyer's proposed terms.
ADP's role is to make an introduction, not to settle SOP data licensing terms. The business and buyer agree their own licence, if they decide to proceed. If personal data is involved, that licence doesn't itself settle privacy obligations. Keep the proposed commercial scope distinct from the checks needed to disclose or process the material lawfully.
Decide whether an introduction is appropriate
Seek company approval for an introduction from someone authorised to speak for the business, based on the collection you can actually describe. Approval to have a conversation is not authority to licence every file in that collection. Give the decision-maker a short account of the material, the unresolved rights questions and the work still needed before any sharing.
Business consent to an introduction isn't a lawful basis for processing personal data, a waiver of confidentiality or proof of copyright and contract authority. Pseudonymised records can still be personal data. If task records may be included, assess them separately. The ICO's guidance on data sharing agreements explains why parties should specify what is shared, for what purpose and with which responsibilities.
If you can describe a bounded collection and identify who can consider an introduction, you have a useful starting point. If ownership or scope is still unclear, finish that sorting work first. ADP's business owner information explains the introduction route. It doesn't approve eligibility, provide a licence or require you to send company datasets to ADP.
Frequently asked questions
Will a folder of standalone SOPs qualify for a licence?
Not necessarily. You can assess the instructions' authorship, dates and scope, but having a manual alone doesn't establish buyer interest or eligibility.
Can we send SOP files to ADP for a decision?
No. ADP does not receive company datasets or decide whether a collection qualifies. Start by describing what your business holds and what it may be able to discuss.
