1. Purpose
The Subprocessor Review Checklist is used to evaluate and approve subprocessors engaged by a supplier to process, store, access, transmit, or otherwise handle the organization’s information or personal data.
The checklist helps determine whether the subprocessor:
- Is necessary for the service being provided
- Handles organizational, customer, or personal data
- Has appropriate security and privacy controls
- Meets contractual and regulatory requirements
- Creates additional supplier or supply-chain risk
- Has appropriate data-location and transfer arrangements
- Has suitable incident, business continuity, and security-assurance capabilities
- Can be approved, approved with conditions, or rejected
The review should be risk-based and proportionate to the type of information, access, service criticality, and regulatory or contractual obligations involved.
2. Core Review Principle
The review should follow:
Supplier → Subprocessor → Service → Information → Processing → Access → Location → Security Controls → Risk → Contract → Approval → Monitoring → Reassessment
A subprocessor should not be treated as simply an administrative disclosure.
The organization should understand what the subprocessor does, what information it receives, why it receives it, where it processes it, what access it has, and what risks it introduces.
3. When to Perform a Subprocessor Review
Perform a review when:
- A new subprocessor is proposed
- An existing supplier introduces a new subprocessor
- A supplier changes an existing subprocessor
- A subprocessor will process personal data
- A subprocessor will receive customer information
- A subprocessor will receive confidential or restricted information
- A subprocessor obtains production or privileged access
- Processing location changes
- Data is transferred to a new country or region
- A new cloud provider is introduced
- A supplier changes its hosting architecture
- A subprocessor experiences a security incident
- A subprocessor’s security assurance expires
- A material regulatory or contractual requirement changes
- Periodic supplier reassessment identifies increased risk
Not every minor supplier relationship requires the same level of review.
4. Subprocessor Review Record
| Field | Details |
|---|---|
| Review ID | Unique identifier |
| Supplier ID | Parent supplier identifier |
| Supplier Name | Primary supplier |
| Subprocessor ID | Unique subprocessor identifier |
| Subprocessor Name | Legal/business name |
| Service | Service provided |
| Business Owner | Internal business owner |
| Supplier Owner | Supplier relationship owner |
| Review Date | Date of review |
| Reviewer | Person conducting review |
| Criticality | Low / Medium / High / Critical |
| Status | Proposed / Under Review / Approved / Rejected |
| Next Review Date | Planned reassessment |
5. Subprocessor Identification
Confirm:
- Legal name identified
- Trading/business name identified
- Parent supplier identified
- Subprocessor service identified
- Purpose of processing documented
- Service dependency documented
- Subprocessor category identified
- Country/region identified
- Relevant website or documentation identified
- Primary contact identified
- Security/privacy contact identified
Evidence
Examples:
- Supplier subprocessor list
- Supplier notification
- Contract
- DPA
- Supplier architecture documentation
- Privacy documentation
- Security documentation
6. Business Purpose Assessment
Document why the subprocessor is required.
| Question | Response |
|---|---|
| Why is the subprocessor required? | |
| What service does it provide? | |
| Is the service business-critical? | |
| Could the supplier provide the service without the subprocessor? | |
| Is there an alternative provider? | |
| Does the subprocessor create additional dependency? | |
| Does it introduce concentration risk? |
The purpose should be specific.
For example:
“The supplier uses AWS for hosting application workloads and customer data.”
is more useful than:
“Cloud provider.”
7. Information Assessment
Identify exactly what information the subprocessor can access or process.
Assess whether it handles:
- Public information
- Internal information
- Confidential information
- Restricted information
- Customer information
- Personal data
- Sensitive personal data
- Authentication information
- Financial information
- Source code
- Security logs
- Business records
- Intellectual property
- Production data
- Backup data
- Metadata
Document:
| Information | Classification | Processing | Access |
|---|---|---|---|
| Customer account data | Confidential | Storage | Application |
| Support tickets | Confidential | Processing | Support system |
| Employee data | Restricted | Processing | Limited |
Use the organization’s approved information-classification model.
8. Personal Data Assessment
Determine whether the subprocessor processes personal data.
Assess:
- Categories of personal data
- Categories of data subjects
- Processing purpose
- Processing activities
- Data volume
- Retention period
- Data minimization
- Access requirements
- Data deletion requirements
- Data-subject rights support
- Privacy incident obligations
- Regulatory requirements
Document whether the subprocessor acts as:
- Processor
- Subprocessor
- Independent controller
- Other legally applicable role
The legal characterization should be confirmed against the applicable law and contractual arrangement.
9. Data Flow Assessment
Document the flow:
Organization → Supplier → Subprocessor → Service/System → Storage/Processing Location
Determine:
- What data is transferred?
- From where?
- To whom?
- Why?
- Through which system/API?
- Where is it stored?
- Where is it processed?
- Is data replicated?
- Is backup data transferred?
- Is data transferred to additional subprocessors?
Where appropriate, maintain a data-flow diagram.
10. Data Location Assessment
Confirm:
- Country of processing
- Country of storage
- Cloud region
- Backup location
- Disaster-recovery location
- Support location
- Administrative-access location
Assess whether processing occurs in:
- India
- United States
- European Economic Area
- United Kingdom
- Other jurisdictions
The relevant legal and contractual requirements should be evaluated for the actual jurisdictions involved.
11. International Data Transfer Assessment
Where cross-border transfers occur, evaluate:
- Transfer mechanism
- Contractual requirements
- Applicable privacy law
- Customer commitments
- Data-residency requirements
- Government-access considerations
- Encryption
- Transfer safeguards
- Subprocessor obligations
- Data-subject implications
Record the applicable transfer mechanism and supporting evidence.
12. Security Assessment
Review whether the subprocessor maintains appropriate controls covering:
Governance
- Information-security policy
- Security governance
- Risk management
- Security responsibilities
- Security awareness
Access Control
- Individual accounts
- MFA
- Least privilege
- Privileged access management
- Access reviews
- Joiner/mover/leaver controls
Technical Security
- Network security
- Endpoint protection
- Vulnerability management
- Secure configuration
- Malware protection
- Security monitoring
Data Protection
- Encryption in transit
- Encryption at rest
- Key management
- Data retention
- Secure deletion
Application Security
Where applicable:
- Secure development
- Code review
- Security testing
- Vulnerability management
- Dependency management
- Change management
13. Cloud Security Assessment
If the subprocessor provides cloud services, evaluate:
- Cloud architecture
- Tenant isolation
- IAM
- MFA
- Privileged access
- Encryption
- Logging
- Monitoring
- Backup
- Disaster recovery
- Vulnerability management
- Security incident response
- Data-location controls
For example, if a supplier uses AWS to process customer information, review the relevant AWS architecture and controls rather than simply recording “AWS is ISO certified.”
14. Access Assessment
Determine the type of access provided to the subprocessor.
| Access Type | Applicable? |
|---|---|
| No access | |
| Application access | |
| Customer-data access | |
| Support access | |
| Administrative access | |
| Production access | |
| Database access | |
| Cloud access | |
| Source-code access | |
| Security-tool access | |
| Privileged access |
For each applicable access type, verify:
- Business justification
- Named accounts
- MFA
- Least privilege
- Approval
- Logging
- Periodic access review
- Timely revocation
15. Subprocessor Personnel Assessment
Evaluate:
- Background verification where appropriate
- Confidentiality obligations
- Security awareness
- Privacy awareness
- Role-based training
- Access authorization
- Joiner/mover/leaver process
- Privileged-user controls
The review should focus on personnel who can actually access the organization’s information or systems.
16. Security Assurance Review
Request appropriate assurance evidence.
Examples include:
- ISO/IEC 27001 certificate
- SOC 2 report
- SOC 1 report where relevant
- Independent security assessment
- Penetration-testing summary
- Security questionnaire
- Business continuity assessment
- Privacy/security documentation
Verify:
- Scope
- Validity
- Issuing organization
- Covered services
- Covered locations
- Exceptions
- Significant findings
- Expiration date
A certification or report should be treated as evidence, not as automatic proof that all risks are acceptable.
17. Incident and Breach Assessment
Confirm whether the subprocessor has documented processes for:
- Security incident detection
- Incident response
- Data breach handling
- Customer notification
- Supplier notification
- Evidence preservation
- Investigation
- Root-cause analysis
- Corrective actions
Confirm contractual notification timelines where applicable.
Also determine whether the supplier is required to notify the organization when a subprocessor experiences a relevant security incident.
18. Vulnerability Management
Assess whether the subprocessor:
- Performs vulnerability scanning
- Performs penetration testing where appropriate
- Tracks vulnerabilities
- Prioritizes vulnerabilities based on risk
- Applies security patches
- Handles critical vulnerabilities
- Monitors third-party components
- Has an emergency remediation process
For technology providers, assess software supply-chain risk where relevant.
19. Encryption and Key Management
Verify applicable controls for:
- Data at rest
- Data in transit
- Backup data
- API communication
- Administrative connections
- Key management
- Key rotation
- Secret management
Do not request or store actual passwords, API keys, private keys, or other secrets as review evidence.
20. Logging and Monitoring
Determine whether relevant activities are logged and monitored.
Examples:
- Authentication
- Privileged access
- Administrative activity
- Data access
- Configuration changes
- Security events
- API activity
- System activity
Assess:
- Log retention
- Monitoring
- Alerting
- Investigation
- Protection against unauthorized modification
21. Business Continuity and Disaster Recovery
Assess:
- Business continuity plan
- Disaster recovery plan
- Backup arrangements
- Recovery testing
- RTO
- RPO
- Service availability
- Redundancy
- Disaster recovery location
- Dependency on other subprocessors
- Recovery communication
For critical subprocessors, evaluate whether their failure could affect the organization’s ability to deliver critical services.
22. Subprocessor Dependency and Concentration Risk
Identify whether multiple suppliers depend on the same subprocessor.
Example:
MAE SaaS → CRM Supplier → AWS
and
MAE SaaS → Support Supplier → AWS
Both relationships may create a common dependency on AWS.
Assess:
- Single points of failure
- Common cloud provider
- Common identity provider
- Common payment provider
- Common communication provider
- Geographic concentration
- Technology concentration
- Supplier concentration
23. Fourth-Party / Further Subprocessor Assessment
Determine whether the subprocessor uses additional subprocessors.
For each relevant further subprocessor:
- Name
- Service
- Data processed
- Location
- Access
- Security assurance
- Criticality
- Risk
The contractual chain should provide sufficient visibility and accountability for relevant downstream processing.
24. Contractual Assessment
Confirm that the supplier’s agreement appropriately addresses:
- Authorization to use subprocessors
- Subprocessor notification
- Security requirements
- Confidentiality
- Data protection
- Incident notification
- Security incident cooperation
- Audit/assurance rights
- Data return
- Data deletion
- Retention
- International transfers
- Further subprocessors
- Termination requirements
Where a DPA applies, confirm that the subprocessor arrangement is appropriately reflected in the contractual structure.
25. Change Notification
Determine how the organization will be informed about:
- New subprocessors
- Replacement subprocessors
- Changes in processing location
- New countries
- Changes in service
- Material security changes
- Ownership changes
- Significant incidents
- Changes to certifications
- Service termination
Document whether the contract provides:
- Prior notification
- Notification within a defined period
- Objection rights where applicable
- Alternative arrangements
- Termination rights where applicable
26. Risk Assessment
Assess risk using the organization’s approved risk methodology.
Consider:
Subprocessor → Information → Access → Dependency → Threat → Vulnerability → Impact → Likelihood → Risk
Consider:
- Information sensitivity
- Personal-data volume
- Customer impact
- Production access
- Privileged access
- Business criticality
- Regulatory requirements
- Geographic exposure
- Security assurance
- Incident history
- Concentration risk
- Availability risk
- Exit difficulty
Example:
| Risk | Likelihood | Impact | Risk |
|---|---|---|---|
| Unauthorized access to customer data through subprocessor | Medium | High | High |
Do not rely only on a generic supplier rating.
27. Risk Treatment
Possible treatments include:
- Additional security requirements
- MFA
- Restricting access
- Removing unnecessary production access
- Encryption
- Additional monitoring
- Contract amendment
- DPA amendment
- Security assurance requirement
- Penetration-test evidence
- Data-location restriction
- Additional incident-notification requirements
- Backup arrangements
- Alternative supplier
- Exit plan
- Risk acceptance
Each treatment should have:
- Action
- Owner
- Due date
- Status
- Evidence
28. Approval Decision
Possible decisions:
- Approved
- Approved with Conditions
- Further Assessment Required
- Deferred
- Rejected
- Accepted as Existing Risk
Document:
- Decision
- Decision-maker
- Conditions
- Risk level
- Exceptions
- Approval date
- Next review date
29. Subprocessor Monitoring
After approval, monitor relevant changes.
Monitor:
- Security incidents
- Breaches
- Vulnerabilities
- Assurance expiry
- Certification changes
- Processing location
- New subprocessors
- Data-flow changes
- Access changes
- Service changes
- Availability
- Contract changes
- Regulatory changes
- Ownership changes
Monitoring frequency should be proportionate to risk.
30. Periodic Reassessment
Reassess the subprocessor when:
- The supplier changes the subprocessor
- The subprocessor changes service
- Data changes
- Data location changes
- New personal data is introduced
- Access increases
- Production access is introduced
- A security incident occurs
- Assurance expires
- Risk increases
- Contract changes
- Regulatory requirements change
- The organization’s dependency increases
31. AWS SaaS Example
Consider a SaaS company providing a customer-management platform.
The SaaS company uses:
- AWS — hosting and storage
- Auth0 — identity/authentication
- Stripe — payment processing
- Datadog — monitoring
- Customer-support platform — support operations
The organization should not simply record:
“Supplier has subprocessors.”
Instead, it should determine:
| Subprocessor | Purpose | Data | Access | Risk |
|---|---|---|---|---|
| AWS | Hosting | Customer/application data | Infrastructure | High |
| Auth0 | Authentication | Identity data | Authentication | High |
| Stripe | Payments | Payment-related data | Payment | High |
| Datadog | Monitoring | Logs/metadata | System telemetry | Medium |
| Support platform | Customer support | Tickets/customer data | Support | Medium |
For AWS, the review may examine:
- Cloud region
- Encryption
- IAM
- MFA
- Privileged access
- Logging
- Backup
- Availability
- Incident response
- Data residency
- Exit/migration considerations
The assessment should reflect the actual architecture and information flow, not just the subprocessor’s name.
32. Critical Subprocessor Assessment
For a critical subprocessor, additionally assess:
- Critical business service dependency
- Customer impact
- Regulatory impact
- Production dependency
- Sensitive-data dependency
- Concentration risk
- Availability
- RTO/RPO
- Disaster recovery
- Alternative provider
- Exit strategy
- Migration feasibility
- Contract protections
- Incident history
- Assurance evidence
- Management approval
Critical subprocessors should generally receive enhanced monitoring and reassessment.
33. Subprocessor Review Summary
| Area | Status | Finding | Action |
|---|---|---|---|
| Business purpose | Pass | Valid requirement | None |
| Personal data | Pass | Customer data processed | Monitor |
| Data location | Pass | Approved region | None |
| Security | Pass | Controls reviewed | None |
| Access | Conditional | Support access required | Review quarterly |
| Assurance | Pass | SOC 2 evidence available | Track expiry |
| Incident | Pass | Notification requirement | None |
| Contract | Conditional | DPA update required | Legal/Security |
| Risk | Medium | Residual risk acceptable | Monitor |
34. Evidence Register
Maintain evidence such as:
| Evidence | Source | Date | Location |
|---|---|---|---|
| Subprocessor list | Supplier | ||
| DPA | Supplier | ||
| Security questionnaire | Supplier | ||
| ISO certificate | Subprocessor | ||
| SOC 2 report | Subprocessor | ||
| Data-flow diagram | Internal/Supplier | ||
| Risk assessment | Internal | ||
| Approval | Internal | ||
| Contract | Legal | ||
| Monitoring record | Internal |
Do not store passwords, API keys, private keys, or other secrets as evidence.
35. Startup-Friendly Review Model
Low Risk
Basic review:
- Subprocessor identification
- Service
- Information
- Location
- Security documentation
- Contractual review
Medium Risk
Add:
- Security questionnaire
- Privacy assessment
- Assurance review
- Data-flow review
- Risk assessment
- Periodic monitoring
High Risk
Add:
- Detailed security assessment
- Access assessment
- DPA review
- Incident requirements
- BCP/DR assessment
- Vulnerability/security testing evidence
- Enhanced monitoring
Critical Risk
Add:
- Management approval
- Detailed dependency assessment
- Concentration-risk assessment
- Exit/migration planning
- Enhanced assurance
- Formal reassessment
- Continuous/event-driven monitoring
These tiers are an organizational model, not prescribed ISO classifications.
36. Roles and Responsibilities
Business Owner
- Identifies business requirement
- Confirms service dependency
- Confirms business impact
Procurement / Vendor Management
- Coordinates supplier information
- Maintains supplier records
- Tracks contractual requirements
Information Security
- Performs security assessment
- Reviews security controls
- Assesses security risk
- Defines security requirements
Privacy / Legal
- Reviews personal-data processing
- Reviews DPA and transfer requirements
- Evaluates applicable legal obligations
IT / Engineering
- Reviews technical architecture
- Reviews access and integrations
- Validates technical controls
Risk Owner
- Reviews risk
- Approves treatment or risk acceptance
Management
- Approves high/critical risks where required by organizational governance
37. Relationship With Other ISMS Documents
The Subprocessor Review Checklist should connect with:
Supplier Register
→ identifies the primary supplier.
Critical Supplier Register
→ identifies critical supplier relationships.
Supplier Risk Assessment
→ evaluates supplier-level risk.
Data Inventory / RoPA
→ identifies personal-data processing.
DPA
→ establishes privacy and processing obligations.
Supplier Security Requirements
→ defines security expectations.
Supplier Security Agreement
→ establishes contractual security obligations.
Supplier Monitoring Register
→ tracks ongoing monitoring.
Supplier Change Assessment
→ assesses material subprocessor changes.
ICT Dependency Register
→ records technology dependencies.
Risk Register
→ tracks significant risks.
Supplier Offboarding Checklist
→ manages termination and data deletion/return.
38. Common Mistakes
Avoid:
- Accepting every subprocessor automatically
- Reviewing only the parent supplier
- Ignoring fourth parties
- Ignoring data location
- Ignoring personal-data processing
- Assuming certification eliminates risk
- Not reviewing production access
- Not checking privileged access
- Not assessing concentration risk
- Not checking incident obligations
- Not tracking assurance expiry
- Not recording approval
- Not monitoring changes
- Not reassessing after a major change
- Treating the checklist as evidence that controls actually operate
39. Internal Audit Checklist
An auditor should be able to verify:
- Supplier identified
- Subprocessor identified
- Business purpose documented
- Service documented
- Information identified
- Personal data assessed
- Data flow understood
- Data location reviewed
- International transfer assessed where applicable
- Security controls reviewed
- Access reviewed
- Assurance evidence reviewed
- Incident requirements reviewed
- BCP/DR reviewed where relevant
- Further subprocessors considered
- Contract/DPA reviewed
- Risk assessed
- Risk treatment documented
- Approval recorded
- Monitoring established
- Reassessment trigger defined
- Evidence retained
40. ISO 27001 Connection
Subprocessor management should support the organization’s risk-based information-security management system and supplier-management controls.
The organization should determine the appropriate level of subprocessor oversight based on:
- Risk assessment
- Information handled
- Supplier criticality
- Access
- Business dependency
- Legal/regulatory requirements
- Customer commitments
- Contractual requirements
- Applicable Statement of Applicability and ISMS controls
The Subprocessor Review Checklist itself is not a universally mandatory ISO 27001 document. It is an organizational mechanism for demonstrating that relevant supplier and downstream-processing risks are identified, evaluated, controlled, monitored, and reviewed.
41. Final Audit Trail
The complete evidence chain should be:
Subprocessor Identified
↓
Business Purpose Confirmed
↓
Service & Information Identified
↓
Personal Data / Data Flow Assessed
↓
Data Location & Transfer Assessed
↓
Security & Access Reviewed
↓
Assurance Evidence Reviewed
↓
Contract / DPA Reviewed
↓
Further Subprocessors Considered
↓
Risk Assessed
↓
Risk Treatment Defined
↓
Approval Recorded
↓
Subprocessor Monitored
↓
Changes / Incidents Tracked
↓
Risk Reassessed
↓
Records Updated / Relationship Closed
Final Principle
A strong subprocessor review should answer seven questions:
Who is the subprocessor?
Why is it being used?
What information does it process?
Where does processing occur?
What access and security controls exist?
What additional risk does it introduce?
How will that risk be monitored throughout the relationship?
The objective is not simply to maintain a list of subprocessors. The objective is to demonstrate that downstream processing remains visible, risk-assessed, contractually controlled, monitored, and aligned with the organization’s information-security and privacy requirements.