When evaluating new intake software, relying solely on SOC 2 badges or ISO certifications is a dangerous trap—a certificate merely confirms that controls exist, not how a platform handles your data. Because an intake system sits in front of your downstream infrastructure, it accumulates highly sensitive commercial intelligence regarding what your organization intends to buy, from whom, and for what project, long before a purchase order is ever generated. Evaluating true procurement intake security requires asking direct, probing questions about data residency, model training, and procurement-specific compliance rather than accepting generic security claims at face value.
In this guide, we break down the exact security, AI governance, and compliance questions you must ask intake vendors before signing a contract. Read on to learn how to bridge the gap between IT security and procurement governance to keep your enterprise data fully protected.
TL;DR
- Ask what happens to your request data, not whether a certificate exists. Certificates confirm controls, not data handling.
- Five data questions: residency, vendor access and logging, treatment of abandoned requests, model training, and the exit path.
- For agentic capability, ask which actions run without a human as a defined list, and what happens when the system is uncertain.
- Three procurement-specific checks a generic security review misses: segregation of duties, audit trail immutability, and delegation.
- See how Merlin Intake handles procurement requests. Request a demo.
Ask what happens to your request data, not whether the vendor holds a certificate. Certificates confirm that controls exist. They do not tell you what the platform does with the information your employees type into it.
An intake platform sits between requesters and every downstream system, which means it accumulates a description of what your organization is buying, from whom, and for what project, before any of it becomes a contract. That is commercially sensitive in a way a purchase order is not, and data privacy in procurement AI is the wider frame.
This is written for procurement teams preparing the security and compliance section of an intake evaluation, working alongside their information security colleagues rather than instead of them.
Where the scope does cover the product, the certificate does real work and the rest of this section becomes a shorter conversation.
What do certifications actually tell you?
That an auditor confirmed controls existed at a point in time, against a scope the vendor defined.
Figure 1 makes the distinction. A certificate is worth having and it is a floor rather than an answer. Two questions turn a certificate into information. Which entity is covered, since a certificate held by a parent company does not necessarily cover the product you are buying. And what was in scope, since the scope statement is where the useful detail lives and is the part rarely read.
Ask for the scope statement rather than the certificate. A vendor who provides it readily has nothing to manage. A vendor who provides only the badge has told you where to look.
The reason these questions matter more for intake than for downstream systems is the stage at which the data exists. A purchase order records a decision already made. An intake queue records what an organization is considering, which supplier it is leaning toward, and what internal project it supports, before any of that is public or committed.
These five are worth asking in this order, because the answers compound. A vendor comfortable with the first four will usually answer the fifth well, and one who becomes vague at the second rarely improves later in the list.
Figure 1: A certificate confirms controls. The scope says what was examined.
Gartner assessed agent governance rather than vendor evaluation. The bearing on this piece is that governance gaps discovered after production are exactly what these questions exist to surface beforehand, and the questions cost nothing to ask.
What should you ask about data handling?
Five questions, and they are about your data rather than their infrastructure.
- Where does request data reside, and can that be constrained? Relevant wherever data residency obligations apply.
- Who at the vendor can read a request, and under what circumstances? Support access is normal. Unlogged support access is not.
- What happens to request data when a request is rejected or abandoned? Abandoned requests contain the same commercial detail as completed ones and are frequently retained by default with no retention policy applied.
- Is request content used to train models, and can that be turned off? This should be answered plainly. An evasive answer here is itself the finding.
- What is the exit path? How your data is returned, in what format, and what is deleted afterward.
The last is the one procurement should care about most, because it determines whether the decision is reversible.
What changes when the platform is agentic?
Two things, and both need asking explicitly.
What actions can the system take without a human? The answer should be a defined list rather than a capability description. If the answer is that it depends on configuration, ask who holds that configuration and how a change is recorded.
What happens when the system is uncertain? A request that cannot be classified should have a defined path. Undefined, it either stalls silently or gets forced into the nearest category, and both are worse than an error.
These are governance questions rather than security questions, and they often fall between procurement and information security because neither owns them. Naming the gap is usually enough to close it.
A practical note on running this well. Send these questions in writing and ask for written answers, then have the conversation. Written answers create a record you can hold a vendor to, and the difference between the written answer and the verbal one is frequently the most informative part of the exercise.
Keep the answers with the contract rather than in the evaluation folder. The questions that matter in an audit are the ones asked before purchase, and nobody can find them two years later.
CAQH measured administrative transactions rather than security evaluation. It is included because that residual manual work is where segregation of duties and audit trail integrity are most often compromised, since manual steps are the ones least likely to be logged.
Which compliance questions apply to procurement specifically?
Three that a generic security review will not cover.
Segregation of duties. Can the same person raise, approve, and receipt a request, and does the platform prevent it or merely record it?
Audit trail immutability. Can an approval record be altered after the fact, and is the alteration visible? This is the question that matters in an audit and it is rarely asked before purchase.
Delegation. When an approver delegates, is the delegation recorded and time-bounded? Standing delegations that nobody revisits are a common finding.
Merlin Intake applies policy before commitment rather than detecting violations afterward, which is the architectural distinction worth probing in any platform: whether controls are preventive or detective. Ask which of the three above are prevented and which are merely logged.
Timing matters too. These questions belong in the evaluation rather than in contracting, because a vendor answering them while competing is more forthcoming than one answering after selection. By contract stage the leverage has moved.
How do you run this without duplicating information security?
Split it by who owns the consequence, as Figure 2 sets out.
Information security owns infrastructure, certification scope, encryption, and access control. Procurement owns data handling in the commercial sense, segregation of duties, audit trail integrity, and the exit path.
Send the standard questionnaire through security, and hold the procurement-specific questions for a session where a product person is present rather than a compliance one. Those questions are usually answered better by someone who built the thing than by someone who documents it.
Figure 2: Two owners, and the boundary between them.
Deloitte surveyed procurement risk broadly rather than vendor security review. The relevance is that the data handling questions above determine whether request data stays reliable, which is the same risk viewed from the vendor side rather than the internal one.
Evaluating procurement intake security goes far beyond checking off standard IT compliance boxes, it is about safeguarding your organization’s sensitive commercial intent and ensuring immutable audit trails across every request. By actively probing vendors on data residency, AI model usage, and segregation of duties before contracting, you ensure your intake layer acts as a preventive security control rather than a downstream risk.
Ready to implement a secure, fully governed front door for all enterprise purchasing? Request a demo today to explore how Zycus Merlin Intake enforces policies, protects commercial data, and streamlines requests seamlessly.
Frequently asked questions
Q1. What security questions should you ask an intake software vendor?
Where request data resides, who at the vendor can access it and whether that access is logged, what happens to rejected and abandoned requests, whether request content trains models, and what the exit path looks like. These concern your data specifically rather than the vendor’s general infrastructure posture.
Q2. Are security certifications enough when evaluating procurement software?
They are a floor rather than an answer. A certificate confirms controls existed at a point in time against a scope the vendor defined, so the useful documents are the scope statement and the entity it covers, not the badge itself.
Q3. What compliance questions are specific to intake platforms?
Segregation of duties, meaning whether one person can raise, approve, and receipt a request. Audit trail immutability, meaning whether approval records can be altered and whether alteration is visible. And delegation handling, meaning whether delegated approval authority is recorded and time-bounded.
Q4. What should you ask about AI and agentic capabilities?
Which actions the system can take without a human, expressed as a defined list rather than a capability description. Who holds the configuration that governs that list and how changes are recorded. And what happens when the system is uncertain rather than wrong, since an undefined path there produces silent stalls.
Q5. Is request data used to train AI models?
That is exactly the question to ask, and it should be answered plainly with a yes or no and a statement of whether it can be disabled. An evasive or heavily qualified answer is itself the finding, regardless of what the eventual clarification says.
Q6. What happens to procurement data if we leave the vendor?
Ask specifically how data is returned, in what format, over what period, and what is deleted afterward including backups. This determines whether the decision is reversible, which matters more for a platform accumulating commercial intelligence than the transactional systems behind it.
Q7. Who should own the security review, procurement or IT?
Split it by consequence. Information security owns infrastructure, certification scope, encryption, and access control. Procurement owns commercial data handling, segregation of duties, audit trail integrity, and the exit path, because those surface as procurement problems rather than technical ones.
Q8. What is the difference between preventive and detective controls in intake?
Preventive controls stop a policy violation before commitment, such as blocking a request that exceeds a threshold. Detective controls record it for later review. Both have a place, and the distinction is worth establishing per control rather than accepting a general claim that the platform enforces policy.
