Enterprise Learning Procurement Explained

By Brian Tr · Updated Oct 6, 2026

Picture the moment an L&D lead says, "We want this." For many EdTech founders that feels like the finish line. It's usually the start of a different race. The L&D lead owns the need. Procurement, security, legal, IT and finance own the purchase, and none of them were in your demo.

Enterprise learning procurement is the set of formal steps a large organization uses to turn a chosen product into a signed, paid, compliant contract. It covers how the buyer asks vendors for information, checks them as suppliers, reviews their security and data handling, tests accessibility, and agrees commercial terms. This article explains each step, what the buyer is actually trying to learn, and how a vendor gets ready before the questionnaire lands. For the wider journey that leads here, start with how companies buy training. By the time procurement is involved, the case for buying has usually been made already, through a training needs analysis and an argument about training ROI.

One caution up front. Procurement practice varies by company, country and whether the buyer is public or private. This article describes common patterns and cites regulations where they exist. It doesn't give typical durations, because no reliable public benchmark exists for learning purchases specifically, and your own pipeline will tell you more than a borrowed average.

Why procurement exists

Procurement is the buyer's way of managing risk it can't see from a demo. A learning product touches employee data, may connect to the company's identity systems, and creates a recurring financial commitment. The people who approve that don't judge pedagogy. They judge exposure.

That's why procurement is a different audience from the L&D team. Where the L&D buyer asks "will our people use this?", the procurement and risk functions ask "what happens if this vendor fails, leaks data, or raises its price?" If you want a general view of the function itself, see procurement management, and for the surrounding group of approvers, stakeholder alignment and the enterprise buying process.

Key Facts: Enterprise Learning Procurement

• A Request for Information (RFI) is a market-research tool. Under the US Federal Acquisition Regulation, responses are not offers and can't be accepted to form a binding contract (FAR 15.201, acquisition.gov).
• Under GDPR Article 28, a processor handling personal data on a controller's behalf must be bound by a contract that sets out the subject matter, duration, nature and purpose of processing, and the type of data involved (Regulation (EU) 2016/679, EUR-Lex).
• A processor may not engage another processor without the controller's prior specific or general written authorisation (GDPR Article 28(2)).
• SOC 2 reports address controls relevant to security, availability, processing integrity, confidentiality or privacy (AICPA & CIMA).
• An Accessibility Conformance Report (ACR) explains how a product meets the Revised Section 508 Standards and helps US federal buyers assess it during market research and proposal evaluation (Section508.gov).

The paper trail: RFI, RFP and RFQ

Large buyers often formalize vendor selection with one or more of three documents. The names get used loosely, so it helps to know what each is for.

Public-sector rules show the logic clearly. The US Federal Acquisition Regulation says RFIs may be used when the Government doesn't presently intend to award a contract but wants market information, and that responses aren't offers. Private companies aren't bound by that rule, but many borrow the same structure because it's defensible: several vendors, the same questions, a scoring sheet.

A few practical points follow.

An RFP often means you weren't the first idea. Sometimes the buyer already prefers a vendor and the RFP is a compliance step. Sometimes it's a genuine open contest. You can't always tell from outside, so ask early what the evaluation criteria and weighting are, and whether you'll get a chance to present.

Answer what's asked. RFP scoring is usually per question. A beautiful narrative that skips a mandatory requirement can lose to a plainer response that covers every line. The mechanics of a good response are covered in RFP response strategy, written for services firms but the discipline carries over.

Decide whether to respond at all. An RFP written around a competitor's feature list is expensive to answer and hard to win. Qualifying out is a legitimate choice.

Vendor onboarding and supplier due diligence

Once you're selected, or sometimes before, the buyer needs to register you as a supplier. This is administrative, and it stalls more deals than founders expect because nobody on the L&D side owns it.

Typical items buyers ask a new supplier for include:

• Legal entity details, registration and tax documentation
• Bank details for payment, usually verified through a separate process
• Insurance certificates, where the contract requires them
• Ownership and financial stability information, especially for a young vendor
• Policies on information security, business continuity and sometimes anti-bribery or code of conduct
• References or a list of comparable customers

Why so much? Because the buyer is protecting itself against dependence on a supplier that disappears. A seed-stage EdTech company is a perfectly reasonable vendor, but the buyer will ask what happens to their learners' records and their access if you cease trading. Vendors that have a plain answer (data export, continuity arrangements, escrow where relevant) look more mature than ones that avoid the question.

The practical fix is a standard "supplier pack" you can send in one email: company documents, policies, insurance, security summary, data processing terms, accessibility report. Building it once saves days on every deal.

Security review

For anything that stores employee data or connects to company systems, expect an information security review. It usually arrives as a questionnaire, sometimes hundreds of questions, and goes to the buyer's security or IT risk team rather than to L&D.

Common contents of a review:

• How data is stored, encrypted and backed up
• Who at the vendor can access customer data, and how that access is controlled
• How incidents are detected and how customers are told about them
• Hosting location and subprocessors
• Independent attestation or certification

On that last point, two reports and certifications come up often.

SOC 2. A SOC 2 report is produced by an independent CPA firm after examining a service organization's controls. The AICPA describes SOC 2 as reporting on controls relevant to security, availability, processing integrity, confidentiality or privacy. Buyers typically ask for the report itself under a non-disclosure agreement, not just a logo. Read the scope before you boast about it: a report that covers only some systems or only some criteria answers fewer of the buyer's questions.

ISO/IEC 27001. This is an international standard for information security management systems, and buyers, particularly outside the US, often ask whether a vendor is certified. If you hold it, have the certificate and its scope statement ready. If you don't, say what you do have instead. Check the current requirements with your certification body before you describe your scope to a buyer.

Early-stage vendors often can't show either. That isn't fatal. A completed questionnaire, a recent penetration test summary, clear policies and a credible roadmap for attestation get many smaller deals through. Larger buyers may still require the report as a condition, so know which deals you can't win yet.

A reusable answer library helps more than any single certificate. Keep your responses to common questions in one maintained place, owned by one person, and reviewed on a schedule. Inconsistent answers across questionnaires are a red flag security reviewers notice.

Data protection and the processing agreement

Learning products process personal data: names, work emails, job roles, progress, assessment results and sometimes performance information. For buyers with EU or UK employees, that triggers data protection law, and the buyer will want a data processing agreement (DPA) in place.

The core rule comes from the General Data Protection Regulation. Article 28 says processing by a processor must be governed by a contract or other legal act that is binding on the processor and sets out the subject matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects. In the usual set-up, your customer is the controller and you're the processor.

The same article lists specific commitments the contract must include. In plain terms, you must:

• Process personal data only on the controller's documented instructions
• Make sure people authorized to process the data are bound by confidentiality
• Apply appropriate security measures
• Assist the controller with data subject requests and with its own compliance obligations
• At the controller's choice, delete or return the data when the service ends
• Make available the information needed to show compliance, and allow and contribute to audits, including inspections

It also deals with subprocessors. The article says a processor may not engage another processor without the controller's prior specific or general written authorisation, and where general authorisation is given, the processor must tell the controller about intended changes so it can object. For an EdTech vendor that runs on cloud hosting, video infrastructure and analytics tools, that means keeping an accurate subprocessor list and a process for notifying customers.

Practical consequences:

• Most enterprise buyers send their own DPA template. Many vendors also have a standard one. Decide in advance which deviations you'll accept and who can approve them.
• Deletion matters in learning more than most categories. Be clear about what happens to learner records and certificates after a contract ends, because compliance buyers sometimes need to keep completion records for years.

This is general information, not legal advice. Your own counsel should review the agreement you actually sign.

Accessibility requirements

Large employers increasingly treat accessibility as a procurement gate, because their workforce includes people with disabilities and, in some places, the law applies to what they buy.

The reference most buyers use is the W3C's Web Content Accessibility Guidelines. WCAG 2.2 covers a wide range of recommendations for making web content more accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, limited movement and some cognitive limitations. Buyers commonly write a target conformance level into the requirements, so ask which version and level they expect.

For US federal and some state buyers, the reference is Section 508. The usual evidence is an Accessibility Conformance Report. Section508.gov describes an ACR as a document that explains how information and communication technology products meet the Revised 508 Standards, and says ACRs help federal contracting officials assess products during market research and when evaluating proposals. Section508.gov also publishes guidance for agencies on requesting accessibility information from vendors, which tells you what a government buyer may ask you for.

Accessibility questions in learning are specific. Expect them to cover:

• Whether course players work with keyboard navigation and screen readers
• Captions and transcripts for video, and alternatives for audio
• Whether third-party content you resell meets the same bar
• Whether authoring and admin screens are accessible, not just the learner view

Don't claim conformance you haven't tested. An accurate report that lists gaps and a remediation plan is more credible than a perfect-looking one, and buyers who care will check.

Integration and SSO requirements

For platforms and content that plug into a learning system, IT will want to know how your product connects. You'll be asked about single sign-on so employees use existing accounts, user provisioning so accounts are created and removed automatically, and how completion data reaches the buyer's learning management system. Standards such as SCORM, xAPI and LTI are the common ways content and tools talk to an LMS. Which one matters depends on the buyer's platform, so ask early what they run. If the buyer's platform is still undecided, LMS vs LXP explains how the two platform types differ.

The risk here is promising an integration you've only half built. Say clearly what's live, what's configurable and what needs custom work, and whether custom work carries a fee.

Contract structures

Once the reviews clear, the commercial paper starts. Enterprise software contracts usually stack several documents.

Splitting the MSA from order forms lets the buyer sign legal terms once and add purchases later without renegotiating. If you expect to expand across departments, that structure works in your favor.

Choices inside the order form deserve attention:

• Licensing model. Seat licenses charge for named or assigned users. Enterprise licences give access to the whole organization, often for a negotiated fee. Learner-based models charge for people who actually use the product. Each shifts risk differently: seat licences punish the buyer if few people log in, enterprise licences punish the vendor if usage explodes. Pricing logic is covered separately in the collection, so here the point is simply to know which model your contract uses and what counts as a "user."
• Term and renewal. Multi-year terms give you revenue visibility and buyers a discount. Auto-renewal clauses are common, but many enterprise buyers push back or require notice periods. Know your renewal terms and calendar them, because the notice window is where surprises happen on both sides.
• Termination and exit. Buyers will ask for the right to leave for material breach, and for data return at the end. Agree what the exit looks like.
• Liability and indemnity. Legal teams negotiate caps and carve-outs hard. Decide in advance who on your side may approve changes.

Payment terms

Payment terms are a procurement topic because the finance function sets them, not L&D. Large buyers often require a purchase order number before they'll pay, so ask which entity to invoice, which currency applies and how tax is handled. Annual billing in advance, quarterly billing and milestone billing for custom work are all normal. Check what your own finance process can support before you offer them. For the budget side of this conversation, see L&D budget cycles, because when the buyer's money becomes available affects what payment schedule they can accept.

How a vendor prepares

Most procurement delays are preparation delays. A reasonable readiness checklist:

1. Build the supplier pack. Company documents, insurance, policies, security summary, subprocessor list, accessibility report, standard DPA.
2. Keep an answer library. One maintained set of responses to common security and RFP questions, with an owner.
3. Know your gaps. If you have no SOC 2 report or ISO certificate, write the honest answer and the plan, rather than improvising on each questionnaire.
4. Pre-agree your negotiating positions. Which DPA changes, liability terms and payment terms can a salesperson accept, and which need escalation?
5. Ask for the process on day one. Who in procurement, security and legal will review, what documents they need, and in what order. Then map those names on your deal plan.
6. Run reviews in parallel. Security, legal and accessibility checks rarely depend on each other. Starting them together, instead of one after another, removes avoidable waiting.

Related reading

• How Companies Buy Training
• Procurement Management
• RFP Response Strategy
• Enterprise Buying Process