Data Security in Procurement AI: What to Demand

The Security Requirements Conversation Starts Here

When evaluating a procurement AI platform, the security conversation should happen early and be detailed. Many procurement teams defer security discussion to IT or compliance, then get stuck when IT has legitimate concerns that procurement cannot answer because they never asked the vendor directly.

This guide provides a structured set of security requirements and vendor assessment questions that procurement and IT teams should discuss together before conducting RFP or vendor evaluation. It is a practical checklist, not comprehensive security audit guidance. For comprehensive security governance framework, see the Procurement AI Security & Compliance Guide.

Encryption: The First Thing to Specify

Encryption is table stakes. Any vendor who hedges on encryption standards is unacceptable. You should demand:

• At Rest (Database): AES-256 or equivalent. The vendor should be able to specify exactly which encryption standard they use, not just "we encrypt everything."
• In Transit (Network): TLS 1.2 minimum, TLS 1.3 preferred. All data moving to/from the platform should be encrypted, including API calls, file uploads, and data exports.
• Key Management: Encryption keys should be managed securely. In multi-tenant platforms (where multiple customers share infrastructure), encryption keys must be isolated per customer — one customer's breach does not expose other customers' data.
• Bring Your Own Key (BYOK) Option: For high-security deployments, some vendors offer BYOK, where you manage the master encryption key and the vendor cannot decrypt your data without your key. This is excellent if offered; do not require it if the vendor has good key management practices.

Red Flags on Encryption

• Vendor cannot specify which encryption standard they use.
• Vendor offers encryption only as a paid add-on feature. Encryption should be default, not optional.
• Vendor uses outdated encryption standards (AES-128, TLS 1.0).
• Vendor cannot explain how encryption keys are managed or who has access to them.

Access Control: Who Can See Your Data?

Encryption protects data if systems are breached. Access control prevents breaches in the first place by restricting who can view data internally. You should demand:

• Role-Based Access Control (RBAC): Users should have access only to the data they need for their job. A procurement analyst should not have access to contract negotiation terms; a spend analyst should not see supplier payment data. The vendor's platform should support role definitions that allow you to enforce this separation.
• Multi-Factor Authentication (MFA): At minimum for administrative accounts (vendor support, administrators, integrations). Ideally, MFA should be available for all users and enforceable via policy.
• Single Sign-On (SSO): Integration with your corporate identity provider (Okta, Azure AD, etc.). This allows centralised user provisioning and deprovisioning; when someone leaves your company, they lose access immediately.
• API Key Management: If the platform exposes APIs (for integrations with ERP, data lake, etc.), API keys should be: (a) rotatable, (b) have expiration policies, (c) include audit logging of all API access, (d) support key revocation immediately.

Testing Access Control in Demos

During vendor demos, specifically ask:

• "Can you show me how we define roles and what data each role can access?"
• "If someone is promoted from Procurement Coordinator to Sourcing Manager, how do we change their role and what happens to their old access?"
• "If someone leaves the company, how long does it take to fully revoke their access (across all systems, including integrations)?"
• "Can we enforce MFA for all users, or only administrators?"

Data Residency and Jurisdiction

Data residency — where your data physically sits — affects both compliance and security. You should know:

• Which regions does the vendor support? If you operate in the EU, can the vendor guarantee that your data stays within EU data centres? If you have HIPAA obligations (healthcare), do they support FedRAMP-certified US data centres?
• Is data residency a contractual commitment or best practice? The difference matters. Contractual = you can terminate the contract if the vendor violates it. Best practice = the vendor will try to honour it but cannot be held accountable if they move your data.
• Are backups in the same region or different regions? For disaster recovery, vendors often keep backups in different regions. Confirm that backup regions meet your data residency requirements.
• Can you request data export and deletion from specific regions? For GDPR compliance, you should be able to request that your EU data is deleted from all regions, including backup systems, within a specific timeframe (typically 30-90 days).

Audit Logging and Access Transparency

Audit logs are your evidence of what happened in the system. Who accessed data? When? What did they do? This is critical for both security (detecting breaches) and compliance (demonstrating you met regulatory obligations).

What Should Be Logged?

• User access: When someone logs in, which data they access, when they log out. Include failed login attempts (indicators of brute force attacks).
• Data operations: Every action taken: view, export, edit, delete. Not just "user accessed spend data" but "user exported spend data for Q1 in CSV format."
• Administrative actions: User provisioning, role changes, access revocation, configuration changes. Track who made the change, when, and what changed.
• Vendor support access: If vendor support engineers access your data to troubleshoot issues, this should be logged. You should be able to know exactly which vendor employee accessed what data and when.
• API access: Which integrations accessed your data, what endpoints they called, how much data they retrieved, any errors.

Audit Log Access and Retention

• You should have access to logs: Not just summaries or "we've reviewed the logs" — you should be able to export logs and analyse them yourself.
• Logs should be immutable: Once written, logs cannot be deleted or modified (even by administrators). This prevents cover-up of breaches.
• Minimum retention: 12 months. Many regulations require longer; 24 months is better for audit trails. Old logs should be archived, not deleted.

Third-Party Security Testing and Certifications

The vendor's own security claims are insufficient. You need independent verification. Demand:

SOC 2 Type II Certification

• Non-negotiable baseline: Any vendor handling sensitive spend and supplier data should have current SOC 2 Type II certification (not Type I, which is weaker).
• Review the report: Request the audit report (or executive summary) and review it yourself. Focus on the Security and Confidentiality sections. Pay attention to any "exceptions" or areas where the vendor's actual practice differed from their stated controls.
• Check the audit date: If the SOC 2 report is more than 18 months old, ask when the next audit is scheduled. Vendors should maintain current certification.

ISO 27001 Certification

ISO 27001 is a complementary certification focusing on information security management systems (ISMS). If the vendor has both SOC 2 Type II and ISO 27001, that is excellent coverage.

Independent Penetration Testing

For high-value deployments (handling $500M+ in spend data), require annual independent penetration testing by a reputable security firm (CrowdStrike, Fortanix, etc.). Pen testing costs $20,000–$50,000 per engagement but is justified when the data at risk is high-value. Ask the vendor who conducts their pen testing and request findings reports.

Breach Notification and Incident Response

No vendor is breach-proof. What matters is how they respond. Demand contractual commitments on:

• Notification timeline: Vendor must notify you of any confirmed breach or suspected breach within 48 hours (GDPR standard) or 24 hours (if possible). Get this in writing.
• What notification includes: Nature of the breach, what data was accessed, who was affected, what the vendor is doing to contain it, what you should do (change passwords, monitor accounts, etc.).
• Incident response process: Vendor should have documented incident response procedures. Ask: "What is your incident response process?" A vendor that has to think about this has not rehearsed it.
• Ransomware and extortion response: What happens if the vendor is hit with ransomware? Will they disclose it? How will they help you assess the impact on your data?

Security Assessment Questions Checklist

Use this checklist when requesting information from procurement AI vendors. Cross-reference with SOC 2 reports and reference calls to validate answers.

Frequently Asked Questions

Conclusion: Security is Non-Negotiable

Procurement AI vendors understand that security is a purchasing criterion. Vendors with mature security practices will answer these questions in detail and support your compliance requirements. Vendors that hedge, avoid specifics, or try to defer security concerns are signaling risk.

Use this checklist early in vendor evaluation. If a vendor cannot meet the baseline security requirements, stop the evaluation and move to the next vendor. There are enough secure options in the market that you should never compromise on security to get a specific feature or lower price.