Vendor Risk Management, Contract Assessment, and DPAs: A Practical Guide

Your cloud provider has a breach. Customer data is exposed. Your customers do not call your cloud provider. They call you.

This is the reality of third-party risk. You are responsible for every vendor that touches your data, whether they are a major cloud platform or a two-person analytics startup. SOC 2 auditors will ask about your vendor management program. ISO 27001 requires documented supplier controls. GDPR makes you legally liable for your processors and their subprocessors.

Most companies handle vendor risk reactively. A procurement form gets filled out. A DPA gets signed without reading it. The vendor is approved and never reviewed again. Then something goes wrong.

This guide covers how to build a vendor risk management program that actually works. Not theory. Practical steps for security leaders at startups and scaling companies.

What Is Vendor Risk Management?

Vendor risk management is the process of identifying, assessing, and continuously monitoring the security risks introduced by third-party suppliers who have access to your systems or data.

Every vendor in your stack is an extension of your attack surface:

• Cloud infrastructure (AWS, GCP, Azure) hosts your production data
• SaaS tools (Slack, GitHub, HubSpot) process employee and customer information
• Payment processors (Stripe, Adyen) handle financial data
• Analytics services (Mixpanel, Amplitude) may collect user behavior data
• HR platforms (BambooHR, Personio) store sensitive employee records

A breach at any of these vendors is, from your customer's perspective, your breach. Vendor risk management exists to ensure you know what risks you are carrying and that those risks are controlled.

Why Vendor Management Matters for SOC 2, ISO 27001, and GDPR

SOC 2

SOC 2 Trust Services Criteria explicitly require vendor management:

• CC9.2: The entity assesses and manages risks associated with vendors and business partners
• CC3.2: Risk assessment includes consideration of external threats, including third parties

Your auditor will ask for a vendor inventory, evidence of risk assessments, and proof that you monitor critical vendors.

ISO 27001

ISO 27001:2022 Annex A includes several supplier-specific controls:

• A.5.19: Information security in supplier relationships
• A.5.20: Addressing information security within supplier agreements
• A.5.21: Managing information security in the ICT supply chain
• A.5.22: Monitoring, review, and change management of supplier services

These are not optional suggestions. They are auditable controls.

GDPR

Under GDPR, if a vendor processes personal data on your behalf, you are the controller and they are the processor. You are legally required to:

• Have a Data Processing Agreement (DPA) in place
• Ensure the processor has adequate security measures
• Know and approve all subprocessors
• Be notified of subprocessor changes
• Ensure data transfers outside the EEA have legal basis

Failure to manage processors properly can result in fines up to 4% of global annual turnover.

Vendor Contract Security Assessment

When reviewing a vendor contract, these are the security clauses that matter:

Security Obligations

• What security measures does the vendor commit to? Look for specific controls (encryption, access management, logging), not vague promises.
• Do they hold SOC 2 Type II or ISO 27001 certification?
• Are they willing to share their audit report?

Data Protection Terms

• What data will the vendor access or process?
• Where is the data stored geographically?
• Is data encrypted at rest and in transit?
• What happens to the data when the contract ends?

Breach Notification

• How quickly must the vendor notify you of a security incident?
• GDPR requires notification "without undue delay." Look for 24 to 72 hour commitments.
• Does the notification include root cause analysis and remediation plan?

Audit Rights

• Can you audit the vendor's security controls?
• Can you request evidence of compliance on demand?
• Are audit results shared transparently?

SLAs and Liability

• What uptime guarantees exist?
• What are the liability caps for security incidents?
• Is there an indemnification clause for data breaches caused by the vendor?

What Is a Data Processing Agreement (DPA)?

A Data Processing Agreement is a legally binding contract between a data controller and a data processor. Under GDPR, a DPA is mandatory whenever a third party processes personal data on your behalf.

When a DPA is required:

• Your SaaS product stores customer data in a cloud database (you are the controller, the cloud provider is the processor)
• You use an email marketing tool that sends emails to your users (the tool is the processor)
• Your analytics platform collects user behavior data (the platform is the processor)
• Your HR tool processes employee personal information (the tool is the processor)

If personal data flows to a third party and they process it under your instructions, you need a DPA.

Processor vs Subprocessor

This distinction is critical and frequently misunderstood.

Processor: A third party that processes personal data on behalf of the controller, under the controller's instructions.

Example: You use Stripe to process customer payments. Stripe is your processor.

Subprocessor: A third party engaged by the processor to assist in processing personal data.

Example: Stripe uses AWS to host its infrastructure. AWS is Stripe's subprocessor, and therefore your subprocessor too.

Why This Matters

Under GDPR:

• You must know all subprocessors in your data processing chain
• The processor must get your approval before engaging a new subprocessor
• You can object to a new subprocessor if they do not meet your security requirements
• The processor remains liable for the subprocessor's compliance

In practice, this means:

Your Vendor	Their Subprocessors	Your Responsibility
Stripe (payments)	AWS, Google Cloud	Know they exist, ensure DPA covers them
HubSpot (CRM)	AWS, Cloudflare, SendGrid	Review their subprocessor list
Slack (messaging)	AWS, Salesforce	Check their DPA and subprocessor page
Your SaaS product	Your cloud provider + all integrated services	Maintain a complete subprocessor list for your own customers

What Must Be Included in a DPA

A compliant DPA under GDPR must include:

• Subject matter and duration of processing
• Nature and purpose of processing
• Types of personal data being processed
• Categories of data subjects (customers, employees, etc.)
• Obligations and rights of the controller
• Security measures the processor will implement (Article 32)
• Breach notification obligations and timelines
• Subprocessor approval process (prior written consent or general authorization with objection rights)
• Data transfer mechanisms for international transfers (SCCs, adequacy decisions)
• Deletion or return of data at the end of the contract
• Audit and inspection rights
• Confidentiality obligations for processor's staff

Subprocessor Risk Management

Building Visibility

Most companies cannot name all their subprocessors. Start here:

1. Ask every vendor for their current subprocessor list
2. Check vendor websites for published subprocessor pages (most major SaaS companies publish these)
3. Subscribe to subprocessor change notifications where available
4. Document the data flow: what data goes to the vendor, and where does the vendor send it?

Ongoing Monitoring

• Review subprocessor lists at least quarterly
• Require vendors to notify you of subprocessor changes before they take effect
• Assess new subprocessors for data residency, security posture, and regulatory compliance
• Maintain the right to object to subprocessors that do not meet your standards

The "Hidden Subprocessor" Problem

A common risk: your vendor adds a new subprocessor, does not notify you, and customer data starts flowing to a service you have never assessed. This is a GDPR violation on the vendor's part, but it is a risk management failure on yours if you were not monitoring.

Vendor Risk Assessment Checklist for Startups

Use this as a starting point. Not every vendor requires the same depth of assessment.

For Critical Vendors (access to customer data, production systems)

• SOC 2 Type II report or ISO 27001 certificate reviewed
• DPA signed and covers GDPR requirements
• Subprocessor list documented and reviewed
• Data residency confirmed (within EEA or with valid transfer mechanism)
• Encryption at rest and in transit confirmed
• Breach notification clause includes timeline (24-72 hours)
• Audit rights included in contract
• Business continuity and disaster recovery capabilities assessed
• Access control and authentication practices reviewed
• Annual reassessment scheduled

For Standard Vendors (limited data access)

• Basic security questionnaire completed
• DPA signed if personal data is involved
• Data types and purposes documented
• Subprocessor list obtained
• Contract includes security and data protection clauses

For Low-Risk Vendors (no data access)

• Vendor purpose and scope documented
• No personal data confirmed
• Basic contract review completed

Common Mistakes Companies Make

No vendor inventory

You cannot manage risk you cannot see. If you do not have a complete list of vendors, you do not have a vendor risk management program. You have a collection of unsigned DPAs and unanswered questionnaires.

No DPA in place

Many companies use vendors that process personal data without a DPA. This is a straight GDPR violation. It is also one of the first things auditors check.

No subprocessor visibility

You signed a DPA with your vendor but never checked who their subprocessors are. Your customer data may be flowing through services you have never heard of, in jurisdictions you have not approved.

Blind trust in big vendors

"They are SOC 2 certified" is not a risk assessment. Large vendors have broad certifications, but the scope may not cover the specific service you use. Read the report. Check the scope.

One-time assessment only

Vendor risk changes. They get acquired. They change infrastructure providers. They suffer breaches. A vendor assessed two years ago is not a vendor assessed today. Vendor management is continuous, not one-time.

How to Operationalize Vendor Management

Build a vendor register

Maintain a central list of all vendors with: name, purpose, data types processed, criticality tier, DPA status, last assessment date, next review date.

Tier your vendors by risk

Not every vendor needs the same scrutiny. Tier by data access and business criticality:

Tier	Criteria	Assessment Depth	Review Frequency
Critical	Access to customer data or production systems	Full assessment + SOC 2/ISO review	Annually
Standard	Limited data access, non-production	Security questionnaire	Every 18 months
Low	No data access	Basic documentation	Every 2 years

Automate evidence tracking

Manual vendor tracking in spreadsheets breaks down at 20+ vendors. Use platforms that:

• Maintain your vendor register with DPA status and assessment dates
• Send questionnaires to vendors and track responses
• Alert you when assessments are overdue or subprocessors change
• Connect vendor risk to your overall security posture
• Generate evidence for SOC 2 and ISO 27001 audits automatically

Security operations platforms like Aertous include vendor management alongside risk scoring, compliance tracking, and evidence collection, so vendor risk feeds directly into your overall program rather than living in a separate spreadsheet.

Review quarterly, not annually

A 15-minute quarterly review of your critical vendor list catches problems early. An annual review discovers them too late.

Conclusion

Vendor risk is business risk. Every third party in your stack is a potential point of failure, and every framework you pursue (SOC 2, ISO 27001, GDPR) requires you to manage it.

The companies that do this well treat vendor management as part of their security operating program, not a procurement checkbox. They know their vendors, understand their subprocessors, have DPAs in place, and review risks continuously.

Start with a vendor inventory. Sign the DPAs. Document the subprocessors. Tier by risk. Review regularly. The audit will take care of itself.

Frequently Asked Questions

What is a vendor risk assessment?

A vendor risk assessment evaluates the security posture of a third-party supplier before and during the business relationship. It typically includes reviewing their security certifications, data handling practices, access controls, breach history, and contractual obligations.

What is a DPA under GDPR?

A Data Processing Agreement (DPA) is a legally required contract between a data controller and a data processor under GDPR. It defines how personal data will be processed, what security measures are in place, how breaches are handled, and how subprocessors are managed.

What is the difference between a processor and subprocessor?

A processor processes personal data on behalf of the controller (your company). A subprocessor is a third party engaged by the processor to assist with processing. For example, if you use HubSpot (processor) and HubSpot uses AWS (subprocessor), you are responsible for knowing about and approving both.

When is a DPA required?

A DPA is required under GDPR whenever a third party processes personal data on your behalf. This includes cloud hosting providers, SaaS tools that handle customer data, email services, analytics platforms, and HR systems.

What should be included in a DPA?

A GDPR-compliant DPA must include the purpose and duration of processing, types of data and data subjects, security measures, breach notification procedures, subprocessor approval process, data transfer mechanisms, deletion/return obligations, and audit rights.

How do you assess vendor security?

Review their SOC 2 Type II report or ISO 27001 certificate. Send a security questionnaire covering access controls, encryption, incident response, and data handling. Check their subprocessor list. Review their DPA terms. Assess based on the criticality of data they access.

Do startups need vendor risk management?

Yes. SOC 2 and ISO 27001 both require documented vendor management. GDPR requires DPAs with all processors. Even before formal audits, knowing who has access to your data and under what terms is fundamental security hygiene.

How does vendor management relate to SOC 2?

SOC 2 Trust Services Criteria CC9.2 requires organizations to assess and manage risks associated with vendors and business partners. Your auditor will expect a vendor inventory, evidence of assessments, DPAs for data processors, and proof of ongoing monitoring.

How often should vendor risk assessments be updated?

Critical vendors (those with access to customer data or production systems) should be reassessed annually. Standard vendors every 18 months. Low-risk vendors every 2 years. Any vendor that experiences a breach, acquisition, or significant change should be reassessed immediately.

What is the "hidden subprocessor" problem?

This occurs when a vendor adds a new subprocessor without notifying you. Your customer data starts flowing to a service you have never assessed. Under GDPR, processors must notify controllers of subprocessor changes. Without monitoring, these changes go undetected, creating compliance and security gaps.