How to map privacy requirements for software vendors in corporate procurement?

Why should privacy be a priority in corporate procurement?

Hiring software vendors is one of the most critical decisions for companies that take privacy and security seriously. Each new tool represents an access point to sensitive data, whether customer information, employee data, or strategic operations.

When the Procurement area doesn't map privacy requirements from the beginning of the process, the company is exposed to contractual, operational, and regulatory risks that can result in fines, breaches, and reputation damage.

This guide was created for procurement professionals who need to translate business objectives into practical privacy controls. You'll learn:

• What to ask for as public evidence
• When it's necessary to escalate to a formal Request for Information (RFI)
• Which specific clauses should be included in contracts and renewals

What are the risks of not evaluating privacy during prospecting?

Leaving privacy evaluation until after vendor selection is a common and costly mistake. Without proper due diligence, your company may:

• Hire vendors without basic security certifications, exposing data to vulnerable infrastructures
• Discover regulatory incompatibilities only during the implementation phase, causing delays and additional costs
• Assume joint liability for privacy incidents caused by the vendor
• Face audits with documentation gaps, without evidence that the vendor meets requirements like LGPD, GDPR, or sector standards
• Lose negotiating power, as contractual changes after signing are more difficult and expensive

The best strategy is to incorporate privacy requirements from the prospecting stage, transforming compliance into a technical selection criterion.

How to translate business objectives into privacy controls?

For the Procurement area to objectively evaluate vendors, it's necessary to transform strategic objectives into measurable technical requirements. Here's how to make this translation:

Objective 1: Protect customer and employee data

Practical controls:

• Valid ISO 27001, ISO 27701, or SOC 2 Type II certifications
• Public privacy policy that specifies legal bases for data processing
• Data encryption in transit (TLS 1.2+) and at rest (AES-256 or higher)
• Role-based access controls (RBAC) and multi-factor authentication (MFA)

Objective 2: Ensure regulatory compliance

Practical controls:

• Compliance documentation with LGPD, GDPR, or applicable sector regulations
• Existence of DPO (Data Protection Officer) or equivalent
• Documented process for fulfilling data subject rights (access, correction, deletion)
• Contractual clauses that define roles (controller/processor) and responsibilities

Objective 3: Minimize operational and contractual risks

Practical controls:

• Documented SLA for security incident notification (ideally < 72h)
• Clear data retention and deletion policy
• Right of audit by the contracting company
• Cyber liability insurance with adequate coverage

What to ask for as public evidence during the prospecting phase?

Before even sending a formal RFI, you can (and should) validate basic requirements using public information. This saves time and eliminates inadequate vendors right from the start.

Essential public evidence:

1. Privacy/Security page on the website

• Check if there's a dedicated section with updated policies
• Confirm if there's explicit mention of security frameworks (ISO, SOC, NIST)

2. Certifications and compliance seals

• Look for visible certifications: ISO 27001, SOC 2, ISO 27701, PCI-DSS (if applicable)
• Verify validity and scope of certifications

3. Trust Center or Security Portal

• Mature vendors offer portals with technical security documentation
• Look for whitepapers, penetration testing reports, and security architecture

4. Privacy Policy

• Should be easily accessible and updated
• Check if it mentions legal bases, international transfers, and data subject rights

5. Public incident records

• Search sources like Have I Been Pwned, CVE databases, and news
• Evaluate the vendor's transparency in handling past incidents

When to escalate to RFI (Request for Information)?

A formal RFI is necessary when public evidence is insufficient or when the vendor will process sensitive data. Send RFI in the following situations:

Scenarios requiring RFI:

Sensitive data processing:

• Personal data of customers or employees
• Financial, health, or biometric data
• Intellectual property or trade secrets

Absence of public certifications:

• Vendor doesn't have visible ISO 27001 or SOC 2
• Young company without compliance history

Complex or critical operations:

• Deep integration with internal systems
• Access to production environments
• Long-term data storage

International transfers:

• Data will be processed or stored outside Brazil
• Need to validate transfer mechanisms (SCCs, BCRs)

Essential questions to include in RFI:

• Governance: Who is the DPO or privacy officer? How does the company manage privacy risks?
• Certifications: Provide updated copies of ISO 27001, SOC 2, or equivalents. When was the last audit?
• Architecture: Where will data be stored (country, region)? What's the network architecture and access controls?
• Incidents: What's the notification process? Were there incidents in the last 24 months?
• Subcontracting: Which subprocessors will be used? How are they audited?
• Deletion: What's the process for permanent data deletion at contract termination?

Which specific clauses should be included in contracts?

Even with a complete RFI, the contract is your last line of defense. Include clauses that transform requirements into legal obligations:

Essential privacy clauses:

1. Role definition "The VENDOR will act as [Processor/Controller] of personal data processed under this contract, as defined by LGPD."

2. Purpose and limitation "Data will be processed exclusively for [specific purpose] and cannot be used for other purposes without prior authorization."

3. Security measures "The VENDOR will maintain valid ISO 27001 certification or implement equivalent controls, including AES-256 encryption and MFA."

4. Incident notification "Security incidents must be notified within 24 hours, with complete report within 72 hours."

5. Right of audit "The CONTRACTOR may audit security controls annually, with 30 days prior notice."

6. Subprocessors "Subcontracting of data processing requires prior written approval, with subprocessor list updated quarterly."

7. International transfer "International transfers only through Standard Contractual Clauses (SCCs) approved by ANPD or equivalent mechanism."

8. Data deletion "Data will be deleted within 30 days after contract termination, with destruction certificate provided."

How to adapt requirements by vendor category?

Not every vendor requires the same level of scrutiny. Adapt your approach according to the type of software and data involved:

Category 1: High risk (CRM, HRM, financial systems)

• Mandatory certifications: ISO 27001 + SOC 2 Type II
• Detailed RFI: Always necessary
• Clauses: All mentioned above
• Audit: Annual with right to surprise audit

Category 2: Medium risk (collaboration tools, analytics)

• Minimum certifications: ISO 27001 or SOC 2
• Simplified RFI: Focus on storage and subprocessors
• Priority clauses: Incident notification, data deletion, subprocessors
• Audit: Annual document review

Category 3: Low risk (internal tools, no sensitive data)

• Certifications: ISO 27001 desirable
• Public validation: Sufficient if data is not personal
• Basic clauses: Confidentiality and use limitation
• Audit: Not mandatory

What are the most common mistakes and how to avoid them?

Mistake 1: Evaluating privacy only in the final phase → Solution: Include privacy requirements in pre-qualification criteria

Mistake 2: Accepting generic statements without evidence → Solution: Always ask for copies of certifications and audit reports

Mistake 3: Not reviewing clauses in renewals → Solution: Treat renewals as new hires, reassessing compliance

Mistake 4: Relying only on vendor self-assessments → Solution: Require third-party evidence (certifications, external audits)

Mistake 5: Not documenting approval justifications → Solution: Keep record of decisions for internal and external audits

How to implement this process in your company?

For the Procurement area to execute this model sustainably, it's necessary to create a structured process:

Step 1: Create a requirements matrix by category

• Classify software types by risk level
• Define minimum requirements for each category
• Document in formal policy approved by Legal and Privacy

Step 2: Build a public evidence checklist

• List URLs and documents that should be verified
• Train the Procurement team to make initial validations
• Automate searches when possible (e.g., verify ISO certifications)

Step 3: Standardize RFI templates

• Create questionnaires by risk category
• Include mandatory and optional questions
• Define SLAs for vendor responses

Step 4: Establish approval governance

• Define authorities: who can approve low/medium/high-risk vendors
• Involve Privacy and Security in critical decisions
• Document exceptions and risk compensations

Step 5: Monitor continuously

• Set up alerts for certification expiration
• Review vendors annually or at renewals
• Update requirements according to regulatory evolution

Why does compliance from prospecting generate competitive advantage?

Companies that treat privacy as a purchasing criterion from the beginning gain multiple advantages:

• Cost reduction: Avoids rework, fines, and post-hiring remediation costs
• Speed: Faster approval processes with fewer back-and-forth
• Quality: Vendors that invest in privacy tend to have more mature products
• Reputation: Demonstrates commitment to privacy for customers and partners
• Resilience: Lower exposure to security incidents and crises

Privacy has ceased to be just a legal compliance issue to become a strategic differentiator. Companies that can evaluate vendors rigorously and efficiently gain market confidence and reduce exposures that can cost millions.

How can Trust This support your corporate procurement?

Trust This developed AITS (AI Trust Score), a platform that centralizes privacy and security information from over 1,500 software vendors. With AITS, your Procurement team can:

• Consult vendor privacy assessments based on 90+ objective criteria
• Compare vendors side by side on issues like certifications, policies, and incident history
• Access consolidated public evidence without having to navigate dozens of sites
• Export reports to document due diligence in audit processes
• Monitor changes in policies and certifications of already contracted vendors

If your company wants to professionalize the software procurement process with a focus on privacy, learn about AITS and see how we can accelerate your evaluations without compromising technical rigor.

Support materials for implementing privacy requirements in software procurement

To facilitate the practical application of this guide in your company, we prepared three visual resources that you can download, print, and share with your Procurement, Legal, and Privacy teams:

Privacy Assessment Flow: Complete diagram showing the five stages of the hiring process (Prospecting, RFI, Analysis, Negotiation, and Signing), with critical privacy checkpoints that must be validated before advancing to the next phase.

Vendor Risk Matrix: Quick reference table categorizing software by risk level (High, Medium, Low), with practical examples of each category, mandatory certifications, and corresponding minimum privacy requirements.

Privacy RFI Checklist: Structured template with essential questions organized in four sections (Governance, Certifications, Architecture & Security, Incidents & Response), ready to be used in vendor evaluation processes.

Download complete PDF kit

SUGGESTED IMAGES FOR CONTENT:

Assessment flow infographic: Diagram showing stages from prospecting to contract signing, with privacy checkpoints at each phase (clean and professional flowchart style)

Risk matrix: Visual table categorizing vendors by risk level (high/medium/low) and corresponding requirements, using color coding (red/yellow/green)

Visual checklist: Document illustration with verification items for RFI, showing main sections like Governance, Certifications, Architecture, and Incidents, in scannable format