Home > Technology and data > Technology contracts and outsourcing
Subprocessor approval process: what the decision maker looks at
A subprocessor request moves fast once the paperwork is complete and stalls the moment a document is missing. The decision maker checks three things in order: who the subprocessor is, what data or system access it touches, and whether the existing contract already covers that category. If those three points align, sign-off usually happens within days. If any point is unclear, the file goes back for clarification before a decision is made. Related process files, including Counterparty reports overview and the deadline, follow the same logic of checking the counterparty before checking the paperwork.
What changes once a request is filed
Filing a subprocessor request starts an internal clock. Until the request is filed, the vendor cannot rely on any approval, express or implied. Once filed, the customer's team is expected to respond within a defined internal window, and silence past that window is treated differently depending on the contract's default rule — some contracts treat silence as approval, others as a standing block. This is the single most consequential clause in the whole process, and it is worth checking before a request is sent, not after.
The practical effect is straightforward. A vendor that files early and with complete documentation controls its own timeline. A vendor that files late, or with an incomplete file, hands control of the timeline to the customer's internal review queue.
What to do
- Vendor identifies the categories of data or access the subprocessor will touch.
- Vendor prepares a short subprocessor profile: identity, location, role, and security posture.
- Vendor files the request through the notice channel named in the contract, not by informal email.
- Customer's reviewer checks the profile against the contract's approved-category list.
- Reviewer escalates to the decision maker if the category is new or the location is outside the agreed list.
- Decision maker records the outcome — approved, approved with conditions, or refused — in writing.
Who decides, and on what timeline
| Stage | Who acts | Typical duration |
|---|---|---|
| Request logged | Vendor's contract owner | Same day as identification of the need |
| Initial screening | Customer's operational reviewer | Within the first few working days |
| Escalation, if required | Customer's decision maker (legal or procurement lead) | Depends on internal queue |
| Recorded outcome | Decision maker, in writing | Closes the file |
The decision maker rarely reviews every request personally. Routine requests — a subprocessor already used for a similar function, in an already-approved location — are cleared at the screening stage. The decision maker is pulled in when a request sits outside the pattern the contract already anticipated. This is also where an electronic notice channel matters: contracts that specify a defined electronic submission method reduce disputes about whether a request was properly filed at all. The same question of what counts as a valid electronic filing comes up outside this cluster too — see Electronic submission in tokenised rights explained for how the same filing logic plays out in a different asset class.
Forks: what changes the outcome
If the subprocessor is already on an approved list for a comparable function, the request is close to administrative — the decision maker confirms rather than deliberates. If the subprocessor is new to the relationship, the reviewer typically asks for the security profile before passing the file up. If the customer does not respond within the contractual window, check the default rule first: some agreements auto-approve on silence, others do not, and reading the clause the wrong way is the most common cause of a stalled rollout.
A separate fork applies where the underlying service itself changes — for example, where service credits or penalty calculations depend on which subprocessor is delivering a component. That question is handled on its own file; see Service credit calculation: what the decision maker looks at for how a subprocessor swap can affect a credit calculation already in progress.
What this page does not decide
This page describes the procedural path, not the substantive test for whether a given subprocessor should be approved on security grounds. Security due diligence, audit rights, and the underlying data-processing terms sit in the contract itself and in the customer's own vendor-risk framework, not in the approval workflow described here. Where the underlying question is which documents evidence a party's identity or authority to act — a recurring issue once a file crosses a border — the answer sits in Document in Estonia and the evidence, one step removed from the approval process itself.
Verified
This description reflects a generic contractual approval workflow as it typically operates once a subprocessor notice clause is in place. It does not summarise any single statute, regulation, or court decision, and none is cited here, because a procedural file of this kind is built from contract mechanics rather than from a numbered legal source. Firms that maintain a standing list of approved subprocessors, including local delivery partners, publish that list separately — see Subprocessors, including local delivery partners overview and the evidence for the current version and the date it was last updated. Reviewed for accuracy on the date this page was published.
Related publications
FAQ
How long does the subprocessor approval process take in practice?
Routine requests for an already-approved category typically clear within a few working days. Requests involving a new location or a new function take longer, because the reviewer escalates them to the decision maker before recording an outcome.
Which documents are needed to start the process?
A short profile of the subprocessor — identity, role, location, and a summary of its security posture — is the minimum. Without this, the reviewer cannot screen the request against the contract's approved-category list, and the file stalls before it reaches the decision maker.
What happens if the other side does not respond?
The outcome depends entirely on the contract's default rule for silence. Some agreements treat a lapsed response window as approval; others treat it as a standing block until an explicit answer is given. Check this clause before filing, not after the window has already passed.