Vendor management gets a request: senior Java developer for the payments platform team, T&M billing, start in two weeks. The framework agreement with the supplier from a few years ago includes an NDA, a GDPR clause, and copyright transfer. Procurement asks about the rate. The third-party risk team asks something else: whether this is an "ICT service" within the meaning of DORA, whether it supports a critical or important function, who is actually performing the work—the supplier's employee or a B2B contractor—and whether the contract contains the provisions under Article 30. If the answers are not in the documents, the start date is postponed, or the supplier is disqualified.
Regulation (EU) 2022/2554 of the European Parliament and of the Council on digital operational resilience for the financial sector (DORA) applies from January 17, 2025 (Article 64). The obligations under Chapter V—Management of ICT third-party risk—rest on the financial entity. The bank or insurance undertaking remains fully responsible for compliance even when using outsourced services (Article 28(1)(a)). In practice, however, these obligations are cascaded down to the supplier through the contract and due diligence. Below, we break them down in terms of what actually changes in IT staff augmentation (body leasing).
Is IT staff augmentation an ICT service?
Article 3(21) defines ICT services as digital and data services provided through ICT systems to internal or external users on an ongoing basis (excluding traditional analogue telephone services). In an answer published in the EIOPA Q&A database (DORA030-2999), the European Commission stresses that the definition is intentionally broad and that the financial entity itself assesses whether a specific service is an ICT service.
A practical guideline is the closed list of service types in Annex III to Commission Implementing Regulation (EU) 2024/2956 (templates for the register of information). It includes, inter alia, S01 – ICT project management, S02 – ICT development (business analysis, software design and development, testing), S04 – ICT security management, and S15 – ICT consultancy. A specialist who continuously writes, tests or maintains software in the bank's systems falls into these categories. The billing model – time and materials (T&M) or fixed price – does not exclude an agreement from Chapter V.
⚡ Two independent tests: ICT service and critical or important function
Test 1 – ICT service (Article 3(21)) determines whether the agreement goes into the register of information and must contain the minimum provisions of Article 30(2). Test 2 – critical or important function (Article 3(22): a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the continued compliance with the conditions and obligations of its authorisation) determines whether enhanced requirements apply: exit strategy (Article 28(8)), concentration risk assessment (Article 29) and additional clauses from Article 30(3). Both tests are carried out by the bank, not the vendor.
The same profile – e.g. a senior backend developer – may fall under two different regimes. For a payment settlement system, they will typically support a critical or important function, while for an internal HR tool they often will not. The hourly rate may be similar (we have compiled indicative ranges in the IT staff augmentation rate overview for 2026), but the contractual package, scope of due diligence and the register entry will not be.
The chain: B2B contractor → vendor → bank
Article 3(18) defines ICT third-party risk as risk relating to services provided by ICT third-party service providers "or by their subcontractors". In Polish staff augmentation models, the specialist is frequently not an employee of the vendor, but a B2B contractor. For the bank, this is an additional link in the chain that must be visible.
For services supporting critical or important functions, Article 29(2) requires the bank to weigh the benefits and risks of further subcontracting – especially when the subcontractor is located in a third country – and to assess whether long or complex chains could impair the monitoring of functions and supervisory oversight. Elements of this assessment are further specified in Commission Delegated Regulation (EU) 2025/532 (RTS on subcontracting, applicable from 22 July 2025). Furthermore, Article 30(2)(b) requires the contract to specify the regions or countries where services are to be provided and data is to be processed, as well as prior notification to the bank of any planned change. A specialist who starts working remotely from another country is precisely such a change.
Before signing the contract: Article 28 and Article 29
Article 28(4) requires that, before entering into a contract, the bank shall: (a) assess whether the ICT service supports a critical or important function, (b) verify whether the supervisory conditions for concluding the contract are met, (c) identify and assess all relevant risks, including concentration risk, (d) carry out due diligence on the ICT third-party service provider and ensure that they are suitable, and (e) identify conflicts of interest.
Article 28(5) permits contracts only with ICT third-party service providers that use appropriate information security standards, and, in the case of critical or important functions, with due regard to the most up-to-date and highest quality standards. The Regulation does not explicitly name ISO/IEC 27001 or SOC 2. The bank determines in its own policy what evidence it requires, the content of which for services supporting critical or important functions is specified by Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024 (RTS supplementing Article 28(10)).
Article 29(1) adds an assessment of concentration risk: whether the ICT third-party service provider is easily replaceable and whether the bank does not accumulate multiple contracts for services supporting critical or important functions with the same ICT third-party service provider or with closely linked providers. In IT staff augmentation, this is a very practical question: how many critical roles are filled by the same vendor and what happens if they disappear from the market.
Register of information (Article 28(3))
The bank shall maintain and update a register of information in relation to all contractual arrangements on the use of ICT services—not only critical ones—distinguishing between contracts supporting critical or important functions and others. At least once a year, it shall report to the competent authority on, inter alia, the number of new contractual arrangements, the categories of ICT third-party service providers and the types of contracts, and shall make the full register available upon request. It shall inform the competent authority in good time about any planned contractual arrangement concerning a critical or important function.
The templates for the register are specified by Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024. In Poland, the KNF (Polish Financial Supervision Authority) indicated LEI as the required identifier for the entity maintaining the register, and registers were submitted using the SPR-PF-18 form (the second stage in May 2025 covered, inter alia, entities that had not submitted the register by 28 April 2025, and registers rejected during validation on the EBA side). According to the KNF's reporting obligations schedule, a planned contractual arrangement for services supporting critical or important functions is reported using the SPR-PF-19 form within 14 days before signing the contract.
Two things follow from this for the ICT third-party service provider. The questionnaire from the bank will ask for data for the register: company identifier, service type from the S01–S19 list, locations of service provision and data processing, and subcontractors in the chain. And in the case of critical roles, "starting on Monday" is unrealistic if formalities do not start in parallel with recruitment.
Exit strategy (Article 28(8))
For ICT services supporting critical or important functions, the bank must have exit strategies that take into account, inter alia, a failure of the ICT third-party service provider, a deterioration of the quality of the services provided, the disruption of business operations, and the termination of contracts in the situations referred to in Article 28(7). The exit shall be possible without disruption to business activities, without limiting compliance with regulatory requirements, and without prejudice to the continuity and quality of services provided to clients. Exit plans must be comprehensive, documented, appropriately tested and periodically reviewed.
In IT staff augmentation, the exit risk has a very specific form: the departure of a key senior specialist, illness, termination of the B2B contract. The bank therefore expects a succession plan (within what timeframe and in what manner a successor will appear), a shadowing period, and documentation that remains on the bank's side—in the repository, wiki and tickets, rather than on the specialist's laptop. However, Article 28(8) goes beyond replacing an individual: the bank must be able to terminate the entire cooperation with the ICT third-party service provider and take over the tasks independently or transfer them to another entity.
Article 30: what must be included in the contract
Article 30(1) requires a clear, written allocation of rights and obligations. The full contract, including service level agreements, shall constitute a single document - in paper format or in another downloadable and accessible format. Paragraph 2 lists the minimum elements of every ICT services contract, and paragraph 3 sets out additional elements for services supporting critical or important functions.
| Element | Paragraph 2 - every ICT services contract | Paragraph 3 - additionally for a critical or important function |
|---|---|---|
| Description of services | Full description of functions and services; information on whether subcontracting of a service supporting a critical or important function is permitted and under what conditions (point (a)) | - |
| Locations | Regions or countries where the services are provided and where data is processed, including storage; prior notification of any change (point (b)) | - |
| Data protection | Availability, authenticity, integrity and confidentiality of data, including personal data (point (c)) | - |
| Access and return of data | Access, recovery and return of data in an easily accessible format in the event of insolvency, resolution or discontinuation of business operations of the ICT third-party service provider, or upon termination of the contract (point (d)) | - |
| Service levels | Descriptions of service levels including updates (point (e)) | Full descriptions with precise quantitative and qualitative targets; remedial actions without undue delay (point (a)) |
| Incidents | Assistance in the event of an ICT-related incident - at no additional cost or at a cost determined ex-ante (point (f)) | Notice periods and reporting obligations of the ICT third-party service provider, including regarding events that may materially affect the provision of the services (point (b)) |
| Authorities | Full cooperation with competent authorities and resolution authorities (point (g)) | - |
| Termination | Termination rights and minimum notice periods (point (h)) | - |
| Training | Conditions for the participation of the ICT third-party service provider in the bank's awareness-raising programmes and digital resilience trainings (point (i), Article 13(6)) | - |
| Business continuity | - | Implementation and testing of contingency plans and ICT security measures (point (c)) |
| TLPT | - | Participation and full cooperation in threat-led penetration testing (point (d), Articles 26-27) |
| Audit | - | Unrestricted rights of access, inspection and audit for the bank, an appointed third party and the competent authority (point (e)) |
| Exit strategy | - | Exit strategies with a mandatory transition period during which the ICT third-party service provider continues to provide the services (point (f)) |
Two things are easy to overlook. The audit right under paragraph 3(e) must be practicable - it cannot be limited by another contract or the internal policy of the ICT third-party service provider. The obligation to provide assistance in the event of an incident (paragraph 2(f)), on the other hand, applies to every ICT services contract, not only to critical ones. How to translate these requirements into a master services agreement and an SOW without losing control over IP and costs is described in our articles on negotiating contracts with software development companies and transparent IT staff augmentation.
ICT incidents: who reports what (Articles 17–19)
The process for managing ICT incidents (Article 17), their classification (Article 18), and the reporting of major ICT-related incidents to the competent authority (Article 19) are obligations of the financial entity. Article 19(4) provides for three stages: initial notification, an intermediate report, and a final report. A bank may outsource reporting to a third party, but remains fully responsible for it (Article 19(5)). In Poland, major ICT-related incidents are reported via the KNF (Polish Financial Supervision Authority) system available at csirt.knf.gov.pl.
Therefore, an IT staff augmentation company does not report an incident to the KNF on behalf of the bank. Its task is to immediately notify the bank when a specialist detects or contributes to an incident related to the service, provide the facts necessary for classification, and grant assistance pursuant to Article 30(2)(f). The contract and the specialist's onboarding should define a specific path: whom to notify, through which channel, and within what timeframe. For strictly security roles, see also body leasing of cybersecurity specialists.
IT staffing provider due diligence checklist
The following list organizes the questions worth asking the provider before signing a contract. This is a working checklist, not a replacement for the bank's policy.
| What to check | What to expect from the provider | Basis |
|---|---|---|
| Whether this is an ICT service and of what type | Description of the role, systems, and working mode; assignment to type S01–S19 | Article 3(21); ITS 2024/2956, Annex III |
| Whether the service supports a critical or important function | Classification by the bank; provider declares readiness to accept clauses from paragraph 3 | Article 28(4)(a); Article 3(22) |
| Subcontracting chain | Form of cooperation with the specialist (employment contract or B2B), entity, country; rules for further subcontracting | Article 29(2); Article 30(2)(a); RTS 2025/532 |
| Locations | Country of work and data processing; change notification procedure | Article 30(2)(b) |
| Information security | Security policy, NDA, access rules; work exclusively on environments approved by the bank | Article 28(5); Article 30(2)(c) |
| Data for the register of information | Company identifier (e.g. LEI), registration details, position in the chain | Article 28(3); ITS 2024/2956 |
| Incidents | Notification path; cost of assistance included in the price or predetermined | Article 30(2)(f); Articles 17–19 |
| Training | Consent to the participation of specialists in the bank's awareness programs | Article 13(6); Article 30(2)(i) |
| Replacement and knowledge | Substitution plan, overlap period, documentation maintained on the bank's side | Article 28(8) |
| Audit, TLPT, exit | Readiness for audit and testing; provision of services during the transition period | Article 28(6); Article 30(3)(d)–(f) |
Body leasing, team leasing, outsourcing: where DORA places its emphasis
DORA applies to each of these models. They differ in who is responsible for the work output, how concentration manifests, and what exit means in practice. The details of the models are described on the collaboration models and IT staff augmentation pages.
| Model | Who directs the work | Concentration risk (Article 29) | Contract (Article 30) | Exit in practice |
|---|---|---|---|---|
| Body leasing / T&M | Bank; provider is responsible for the individual, the chain, and substitution | Increases when a single provider fills multiple critical roles | Always paragraph 2; paragraph 3 when the role supports a critical or important function | Replacement of the individual or takeover of the role by the bank |
| Team leasing | Provider organizes the team composition and work rhythm; bank sets the objectives | Higher – multiple roles with a single provider (Article 29(1)(b)) | Paragraph 2; for a critical or important function, paragraph 3 (SLAs, audit, TLPT, transition period) | Handover of the entire team and knowledge |
| Outsourcing / managed service | Provider is responsible for the work output or service maintenance | High in case of low substitutability and subcontractors in third countries | Paragraph 2 and typically paragraph 3 | Migration of the service and data to another provider or in-house |
Anti-patterns
- "It's just body leasing, DORA only applies to the cloud." The definition under Article 3(21) and ICT services types S01–S19 encompass software development, testing, security, and ICT consultancy. Time & Materials (T&M) billing changes nothing here.
- Hidden B2B chain. The agency signs a master services agreement, but a contractor from another intermediary works on the project. The bank does not know who is providing the service and therefore cannot reliably assess subcontracting (Article 29(2)) or correctly complete the register of information.
- Lack of an exit strategy / replacement plan. Knowledge about the deployment pipeline resides solely in the head of a single senior developer. For critical or important functions, Article 28(8) and Article 30(3)(c) and (f) require business continuity plans and transition periods – a declaration of "best efforts" will not replace them.
- Audit on paper only. An audit clause is included in the annex, but the supplier's internal policy does not permit granting access to an auditor. Article 30(3)(e) requires that the exercise of these rights is not limited by other provisions.
How Commoditech works
Since 2012, Commoditech has been providing IT specialists through IT staff augmentation and contracting models. We do not classify functions on behalf of the bank and we do not maintain its register of information—these are the obligations of the financial entity. Our role is to act as a provider that can be reliably assessed, entered into the register, and audited:
- Transparent margin – the client knows exactly what portion of the rate goes to the specialist and what goes to the provider (how transparent IT staff augmentation works).
- Transfer of 100% of economic copyright in the generated code to the client.
- Verified specialists – technical verification before presenting a candidate profile.
- Transparent subcontracting chain – information on the form of cooperation and the specialist's country of work, as well as readiness for a clause prohibiting further subcontracting without the bank's consent.
- Readiness for clauses under Article 30 – paragraph 2 in every contract, and paragraph 3 where the bank classifies the service as supporting a critical or important function.
- Handover and replacement plan included in the contract rather than declared verbally.
- Cooperation with audits and tests conducted by the bank, a mandated entity, or a competent authority.
We do not claim certifications we do not hold. If the bank's policy requires a specific certification from the provider, we state this upfront during the qualification stage. If you are preparing a demand for specialists for an environment covered by DORA, contact us – we will start with the list of data needed for your register of information and due diligence.
🛠️ From practice: what a DORA discussion looks like when ordering a specialist
A typical scenario, without names and figures. The procurement department sends a request for a senior backend developer for a system that the bank classifies as supporting a critical or important function. At the same time, the third-party risk team sends a questionnaire: ICT services type, locations of service provision and data processing, list of subcontractors, incident reporting pathway, audit rights, exit transition period, participation in security training.
The response "we work on a T&M basis, the rest is per the master agreement" usually ends the discussion before candidate verification even begins. A provider that immediately discloses the chain (e.g. a B2B contractor from Poland, with no further subcontracting), the place of work, ready-to-use clauses under Article 30(3), and a replacement plan in the SOW moves on to the actual competency assessment. DORA does not replace a technical interview – it sets the gate without which the interview never begins.
FAQ
Is every IT staff augmentation agreement with a bank an ICT service within the meaning of DORA?
The assessment rests with the financial entity, and the definition in Article 3(21) is intentionally broad. Annex III to ITS 2024/2956 covers, inter alia, ICT development (S02), ICT security (S04), and ICT consultancy (S15), so the continuous work of a specialist within bank systems typically falls within this definition.
When does a T&M agreement for a single person require the clauses from Article 30(3)?
When the service supports a critical or important function (Article 3(22)). The number of individuals does not matter: paragraph 2 applies to every ICT services contract, and paragraph 3 is added whenever the bank classifies the function as critical or important.
Is a vendor's B2B contractor a subcontractor that the bank must know about?
If they actually perform the service - yes. Article 3(18) covers risks related to the ICT third-party service provider's subcontractors, and for critical or important functions, Article 29(2), Article 30(2)(a), and RTS 2025/532 require the assessment and regulation of subcontracting.
Who reports a major ICT-related incident to KNF (Polish Financial Supervision Authority) - the bank or the staff augmentation company?
The financial entity (Article 19), via the KNF system at csirt.knf.gov.pl. The provider notifies the bank and assists in handling the incident (Article 30(2)(f)). The bank may outsource reporting to a third party, but ultimate responsibility remains with the bank (Article 19(5)).
Does a specialist provider need ISO 27001 to cooperate with a bank?
DORA does not mandate a specific certificate. Article 28(5) refers to appropriate information security standards, and detailed expectations are set by the bank's policy - which may require a certificate, an audit, or other evidence. A complete lack of documented security rules and audit readiness in practice disqualifies a provider.
Sources
- Regulation (EU) 2022/2554 of the European Parliament and of the Council (DORA) – EUR-Lex
- Commission Implementing Regulation (EU) 2024/2956 (templates for the register of information, Annex III – types of ICT services) – EUR-Lex
- Commission Delegated Regulation (EU) 2024/1773 (RTS on the policy on ICT services supporting critical or important functions) – EUR-Lex
- Commission Delegated Regulation (EU) 2025/532 (RTS on subcontracting of ICT services supporting critical or important functions) – EUR-Lex; EBA
- KNF (Polish Financial Supervision Authority) – DORA; register of information and LEI; second stage of register submission (SPR-PF-18); summary of reporting obligations; DORA systems and incident reporting
- EIOPA – Q&A DORA030-2999 (definition of ICT services); DORA
- EBA – DORA
- ESMA – DORA
This article is for informational purposes only and does not constitute legal advice. The classification of the ICT service and the critical or important function, the contract content, and the entry in the register of information depend on the specific circumstances and the financial entity's policy. The binding text is that of the regulation, implementing acts, and the positions of the supervisory authority (in Poland, KNF).