Delegated Regulation (EU) 2024/1773: ICT services policy

What the DORA ICT services policy RTS requires your organization to write down

A financial entity that relies on ICT providers for critical or important functions must write down how it chooses, contracts for, monitors and exits those providers. Commission Delegated Regulation (EU) 2024/1773 supplements DORA Article 28(10) and sets the content of that policy. It was published in the Official Journal on 25 June 2024. The policy has to be reviewed by the management body at least once a year, must set a method for deciding which ICT services support critical or important functions, and must name the role or senior manager responsible for monitoring those arrangements. The underlying risk is concentration and loss of control over outsourced ICT, where a single provider failure or an unclear exit route can stop a function the entity cannot afford to lose.

The policy must cover every phase of the contract lifecycle: management body responsibilities, planning with a pre-contract risk assessment and due diligence, involvement of business units and control functions, implementation and monitoring, documentation and the register of information, and exit and termination. The pre-contract risk assessment has to consider operational, legal, ICT, reputational, data protection, data availability, data location, provider location and ICT concentration risks. The policy also has to state how assurance on each provider is obtained, such as the entity's own audits, independent audit reports, the provider's internal audit reports or appropriate third-party certifications, and it should draw on more than one source where that makes sense. Confirm with your supervisor and counsel how each of these elements maps to your existing outsourcing procedures before you rewrite them.

Two decisions usually cause the most trouble. The first is scoping: deciding which services count as supporting critical or important functions, including open-source and self-hosted software that the entity runs in its own infrastructure. The second is consistency. The policy, the contract templates, the exit plans and the register of information must describe the same providers, the same functions and the same roles. An inventory of ICT arrangements that is reconciled against the policy and contracts before your annual review is a practical first check. Confirm the current text of the Regulation directly on EUR-Lex before finalizing wording, since the policy must reflect the articles as adopted.

Which ICT services and teams fall under the policy

The policy only works if the organization decides early what counts as an ICT service, which services support critical or important functions, and who must take part. Each card below is a scoping decision that changes the policy's content and the work needed to carry it out.

Services supporting critical or important functions

Article 3 requires the policy to set a methodology for deciding which ICT services support critical or important functions, and those services carry the heaviest requirements, including independent review and inclusion in the audit plan. Document the methodology, apply it to each function in the business continuity and risk inventory, and record the reasoning so an assessor can follow why a service was or was not classified. Confirm the criteria with the management body before the first annual review.

Intra-group ICT services

Services bought from a parent, sister company or shared service center are still ICT third-party arrangements under the policy, even though no external contract is signed. Decide whether intra-group arrangements sit inside the same contract lifecycle, risk assessment and register of information as external providers, and who signs for each side. Groups that shortcut this step often find their intra-group services missing from the register.

Cloud and SaaS providers

Cloud and SaaS arrangements are where the pre-contract risk assessment under Article 5 usually produces the most findings, including data location, provider location and ICT concentration risk. Inventory every subscription that holds or processes entity data, including those bought by business units on corporate cards. Ask each provider for its subcontracting chain and data location commitments before signing, not after.

Self-hosted open-source software on third-party hosting

Open-source software that the entity runs on infrastructure rented from a third party is still an ICT service, even though no license fee is paid to the software maintainer. Decide who provides support, patches and hosting, and treat the hosting provider and any managed-service partner as ICT third-party providers in their own right. Confirm that the entity can exit the hosting arrangement and move the software without losing data, since exit planning applies here as well.

Business, procurement, risk, legal and security roles

The policy must name the role or senior manager responsible for monitoring the arrangements, and each phase of the contract lifecycle needs input from more than one team. Business units define the function and its tolerance for disruption, procurement runs the sourcing, risk and information security assess the arrangement, and legal reviews contract terms. Write a RACI for each lifecycle phase so that no phase depends on one person's memory.

Audit and internal review ownership

Article 3(7) requires services supporting critical or important functions to be subject to independent review and included in the audit plan, so internal audit needs a defined role in the policy rather than a general reference. Agree which team performs each assurance activity, how findings reach the management body, and how gaps are tracked to closure. Auditors will look for evidence that independence is real, not only written down.

How to decide which ICT services support critical or important functions

Article 3 of Delegated Regulation (EU) 2024/1773 requires the policy to set a methodology for deciding which ICT services support critical or important functions, and that decision is the first input to nearly everything that follows. The methodology determines which contracts must contain the full set of elements required under DORA Article 30, which services get independent review and a place in the audit plan, and how deep the pre-contract risk assessment and due diligence need to go. A weak method produces either a register full of services that were never assessed properly or a set of critical arrangements that were never subjected to the controls they need. Treat the methodology as a control in its own right, not as a preliminary paperwork step.

A defensible method records four things for each function the entity performs: the function itself, the impact that a disruption would have on the entity's ability to meet its obligations, the ICT services that support that function (including indirect dependencies such as hosting, identity, monitoring and subcontractors), and the named person who approved the classification. The approver should be accountable for the decision, and the record should show the reasoning, not only the outcome. Ask for the rationale behind any service classed as non-critical that sits close to a critical function, because assessors often test those boundary decisions first. The rules must be applied consistently across business units, including self-hosted open-source platforms that the entity runs itself, since the classification follows the function rather than the licensing model.

The method must be applied to the current service inventory and reviewed at least once a year, with the management body's review evidenced in its minutes. Each review should check whether new functions have been added, whether services have changed their role or subcontracting chain, and whether incidents or audit findings have shown that a classification was wrong. Confirm with your competent authority and your own legal team how the annual review interacts with your existing governance calendar, and keep the version history of the methodology so you can show what changed and why. Document any reclassification and trace it through to the contract, assurance and exit plan for the affected service.

How an assessor tests the ICT services policy

This table compares each major element of the ICT services policy under Delegated Regulation (EU) 2024/1773 with the test approach a competent authority typically takes, the evidence it requests and the findings that recur. Read it as a checklist for what to prepare before a supervisory inspection, and note that the competent authority decides how far each test goes.

Element	Test approach and evidence requested	Common findings
Annual management body review (Article 3)	Assessor checks minutes showing the management body reviewed the policy in the last year, what it challenged, and any changes approved. Evidence: dated minutes, review papers, version history.	Review recorded as a formality with no substantive challenge, or the annual cycle lapsed.
Methodology for critical or important functions (Article 3)	Assessor walks through how a function was classified, tracing the method to the criteria in the policy and to a sample of classified services. Evidence: the written methodology, classification records, inventory of ICT services.	Methodology exists but classification is inconsistent across business units, or key services are not on the list.
Named responsible role or senior manager (Article 3)	Assessor confirms the named role exists, holds the monitoring mandate, and can explain what it monitors. Evidence: role description, organisation chart, reporting lines, monitoring reports.	Named role is vacant, delegated without authority, or unknown to staff who run the contracts.
Lifecycle coverage (Article 4)	Assessor maps each lifecycle phase (management body duties through exit and termination) to a policy section and to the procedure that operates it. Evidence: lifecycle map, linked procedures, register of information entries.	Exit and termination phases are missing or only generic, or planning is documented but monitoring is not.
Pre-contract risk assessment (Article 5)	Assessor selects recent arrangements and checks that the assessment covers each risk category named in the Article, including data location, provider location and ICT concentration. Evidence: signed assessments dated before contract signature.	Assessments completed after signature, or concentration and data location risks not addressed.
Assurance sources (Article 6(3) and (4))	Assessor checks which assurance sources the policy names (own audits, independent audit reports, provider internal audit, certifications) and whether more than one source is used where appropriate. Evidence: assurance plan per provider, audit reports received, follow-up records.	Policy lists sources in general terms, but files show reliance on a single certificate with no review of its scope.
Independent review and audit plan (Article 3(7))	Assessor confirms ICT services supporting critical or important functions are independently reviewed and appear in the audit plan with dates. Evidence: audit plan extract, scope of review, reports and management responses.	Services are missing from the audit plan or reviews cover the provider but not the service the entity actually uses.
Contract content (Article 8 with Article 30(2) and (3))	Assessor samples contracts for critical or important functions and checks each required element against the list in DORA. Evidence: executed contracts, clause mapping, legal review notes.	Contracts lack a required element such as audit access, exit assistance or data location, often because older contracts were never updated.

How to build the policy from scratch in eight steps

This sequence takes an organization from an undefined position on third-party ICT services to a management-approved policy that covers the lifecycle, risk assessment, assurance, conflicts, monitoring and exit required by Delegated Regulation (EU) 2024/1773. Each step closes with a document or decision that the next step depends on.

Confirm scope and the critical or important function method
The management body or the delegated owner confirms which legal entities, group units and ICT arrangements the policy covers, then adopts the methodology the policy must set out for deciding which ICT services support critical or important functions. The method should state the criteria, who applies them, and how borderline cases are escalated. The output is a signed scope statement and a written method, which the reader should check against the Article 3 requirements before moving on.
Map ICT services to business functions
Business owners and the ICT function list every ICT service in use, including cloud, SaaS, managed services, intra-group services and self-hosted open-source platforms the organization operates under contract or support arrangements. Each service is then tagged against the adopted method to show whether it supports a critical or important function. The output is a service-to-function map with a named owner for each entry, and the reader should confirm that no service is left unassigned.
Draft the lifecycle sections of the policy
The policy team writes one section for each phase of the contract lifecycle: management body responsibilities, planning, involvement of business units and controls, implementation and monitoring, documentation and the register of information, and exit and termination. Each section names the accountable role and the records it produces. The output is a complete draft that a reviewer can walk from planning through termination without finding a gap.
Define the pre-contract risk assessment and due diligence
The team sets out the pre-contract assessment the policy requires, covering operational, legal, ICT, reputational, data protection, data availability, data location, provider location and ICT concentration risks. It also defines the due diligence steps that run before signature and the approval level for a decision to proceed. The output is a risk assessment template and a due diligence checklist, with the reader confirming that each listed risk category has a documented question and an owner.
Set the assurance sources for each provider
The policy must state how assurance on each provider is obtained, such as the organization's own audits, independent audit reports, the provider's internal audit reports or appropriate third-party certifications. The team selects which sources apply to which risk tier and records where more than one source is needed. The output is an assurance matrix that links each critical or important service to its evidence sources and a responsible reviewer.
Write conflict of interest and monitoring rules
Procurement, risk and business owners draft rules that identify and manage conflicts of interest in provider selection and oversight, and they assign the role or senior manager responsible for monitoring each arrangement. The monitoring section sets review cadence, performance and risk indicators, and the escalation path to the management body. The output is a conflicts register template and a monitoring schedule, which the reader should confirm names a person rather than a team for every critical or important arrangement.
Specify exit requirements and termination triggers
The team defines the exit requirements the policy applies to critical or important services, including the conditions that trigger termination, the transition steps, and the handling of data and documentation at exit. Legal and ICT owners test the exit approach against the contract terms and the register of information entries. The output is an exit requirements schedule linked to each relevant service, and the reader should check that every entry has a named exit owner and a documented data return or deletion route.
Obtain management body approval and schedule the annual review
The complete policy goes to the management body for approval, with the scope, method, service map and open items attached so that members can see what they are endorsing. The approved version is recorded with its date and version number, and the annual review is placed on the governance calendar with a named owner. The output is a signed approval record and a review schedule, and the reader should confirm that the policy names the monitoring role and that the next review date is set.

Evidence that satisfies the policy requirement and how to keep it current

Article 3 and Articles 4 to 6 of Delegated Regulation (EU) 2024/1773 turn into a small set of records an assessor will ask for. Each card below names one artifact, what it proves, and the routine that keeps it accurate between examinations. Your organization owns these records; an implementation partner can help structure them, but only your competent authority or independent auditor assesses them.

Approved ICT services policy and review trail

The policy itself, with the management body's dated approval and a version history showing each annual review. Assessors look for evidence that the management body reviewed the policy at least once a year, not just that a policy exists. Keep the approval minutes next to each version, record what changed and why, and confirm that the policy names the role responsible for monitoring the arrangements. Wiki tools with built-in version history can hold the document, but the approval minutes still need to live in your governance records.

Critical or important function methodology

The documented method the policy uses to decide which ICT services support critical or important functions, and the decision record for each service classified. A useful record names the function, the services it depends on, the criteria applied and the approver. Re-run the methodology when a function changes, when a provider is added, or at each annual review, and keep superseded decisions rather than overwriting them so you can show how a classification was reached at the time.

Named role or senior manager record

The record that identifies the role or senior manager responsible for monitoring ICT third-party arrangements, with the appointment date, reporting line and the scope of responsibility. Assessors check that the named person matches what staff actually do, so confirm that the monitoring activity appears in their objectives or workplan. Update the record on every change of post holder and keep the earlier appointments on file to show continuity.

Pre-contract risk assessments

A risk assessment completed before each contract for an ICT service that supports a critical or important function. Article 5 expects coverage of operational, legal, ICT, reputational, data protection, data availability, data location, provider location and ICT concentration risks. Date each assessment, record the reviewer and the decision taken, and revisit it when the contract is renewed, the provider changes its subcontracting or the service scope expands.

Assurance records for providers

The file showing how assurance on each provider was obtained under Article 6: your own audits, independent audit reports, the provider's internal audit reports and any appropriate third-party certifications. Article 6 expects more than one source where appropriate, so note which sources you used and why. Track the scope and validity period of each report or certificate, and log the date you reviewed it and any gaps you followed up with the provider.

Exit plans for each supporting service

A documented exit plan for each ICT service supporting a critical or important function, covering how the service would be transferred or stopped and how data would be returned or deleted. Test the plan with a tabletop exercise or a recorded dry run, and record the result. Review the plan when the architecture, the provider or the data location changes, because an exit plan written for a previous setup often fails when it is needed.

What meeting the ICT services policy requirement costs

This table compares the cost components of building and running the ICT services policy that Delegated Regulation (EU) 2024/1773 requires, showing who is paid, whether each cost is one-time or recurring, and what pushes it up. No prices or durations are stated because none are supplied, so use the drivers to frame your quote requests. The main takeaway is that most of the recurring cost comes from the number of critical or important services and the contract backlog, not from the policy document itself.

Cost component	One-time or recurring	What drives it up	How to keep it down
Policy drafting and legal review	One-time, then reviewed annually	Number of contract types, multiple entities in a group, legal review cycles with outside counsel	Reuse a single template, limit the policy to DORA scope, agree review owners early
Management body time	Recurring (annual review and approval)	Complex governance structure, unclear approval steps, late papers that need rework	Prepare a short briefing pack, record the methodology and monitoring role clearly so approval is a review, not a redesign
Engineering and risk time to map services	One-time, then recurring as services change	Large number of ICT services, unclear ownership of each service, undocumented dependencies on other providers	Start from the register of information, assign one owner per service, use a single methodology for critical or important classification
Tooling and licenses	Recurring	Commercial governance or GRC suites priced per user or per module, add-on modules for third-party risk	Self-hosted open-source tooling can remove license spend, but confirm feature fit and hosting cost in your own environment
Internal effort for tool operation	Recurring	Self-hosted tools need administration, patching, backup and access control inside your own infrastructure	Assign a named platform owner, include the tools in your change and backup processes, document the setup
Evidence upkeep for the annual review	Recurring	Contracts and due diligence files scattered across teams, manual collection of assurance reports	Keep one evidence index per provider, use version history so the reviewed state is provable, set a fixed collection calendar
Independent review of critical services	Recurring, usually scheduled	Number of critical or important services in scope, depth of review, first-time reviews of new providers	Set review depth by risk tier, rely on existing independent audit reports where they cover the service, ask for scope confirmation in writing
Auditor or assessor sampling time	Recurring, at each supervisory or external review	Number of contracts sampled, gaps between the policy and actual contracts, incomplete exit plans	Keep the policy, register and contracts aligned before review, prepare a sample pack for each critical service
Contract backlog remediation	One-time, but often recurring when new contracts arrive	Large number of legacy contracts without the Article 30 elements, late identification of critical functions	Prioritize contracts for critical or important functions first, add a contract checklist to procurement

Which open-source tools can hold the policy evidence

The ICT services policy is only as useful as the records behind it: the annual review, the register of ICT services, the risk assessments and the provider assurance file. Three open-source tools can each hold part of that record, but none of them replaces the policy decisions or the judgment of the people who make them.

CISO Assistant for assessments

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including DORA, and can run audits and compliance assessments against them with automatic mapping between frameworks. It can track the policy's requirements, the critical or important function determinations and the assurance status of each provider. It does not decide which services support critical or important functions, and it does not produce the ex-ante risk assessment content. Confirm the current DORA framework content and assessment features in the project documentation, and check that the AGPL-3.0-only terms fit how you plan to modify or host it.

XWiki for version history

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. You can compare any two versions and roll back to an earlier one, which helps show when the policy was reviewed and what the annual review changed. It does not check whether the review happened on time or whether the content is correct, so the review sign-off must still be recorded by the responsible senior manager. Confirm the versioning behavior in your installed version and its retention settings.

BookStack for controlled access

BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. You can restrict who may edit the ICT services policy and who may only read it, and keep the register extracts and provider files in separate books. It does not provide versioned comparison of page content, and it does not enforce an approval workflow, so pair it with a review record. Confirm the permission model in the current documentation against your access policy before you rely on it for DORA evidence.

Gaps no tool covers

None of the three tools decides whether a service supports a critical or important function, performs the pre-contract risk assessment or judges whether provider assurance is sufficient. Those are management body and risk function decisions that must be recorded with a named owner and a date. Ask your implementation partner to design the evidence file so each decision links to the supporting record, and to confirm where each record lives. Expect this design work to be a separate line in the scope and quote.

Who does what: your team, an implementation partner and the auditor

Your organization owns the ICT services policy in full. Under Delegated Regulation (EU) 2024/1773, the management body must approve the policy and review it at least once a year, and the policy must name the role or senior manager responsible for monitoring the arrangements. Decisions about which ICT services support critical or important functions, and the contracts that follow from them, remain your responsibility, even when a partner helps analyze them.

Policy approval and annual review: The management body approves the policy, reviews it at least once a year and records its decisions.
Critical function decisions: Your business and risk owners decide which functions are critical or important and which ICT services support them, using the methodology the policy sets.
Contracts and pre-contract assessments: Your legal, procurement and risk teams negotiate contracts that include the elements required by DORA Article 30 and sign off the risk assessment before signing.
Assurance and exit decisions: You decide how assurance on each provider is obtained and maintain the exit strategies for critical services.
Named monitoring owner: A senior manager you appoint runs ongoing monitoring and escalates issues to the management body.

Confirm with your legal counsel which internal approvals and sign-offs your supervisor expects for the policy and for each critical contract.

Where organizations fall short on the ICT services policy

Most gaps in the ICT services policy trace back to a policy that exists on paper but is not run through the contract lifecycle. The cards below cover the places where Delegated Regulation (EU) 2024/1773 is most often missed, and the fix for each.

No written methodology for critical functions

The policy must set a methodology for deciding which ICT services support critical or important functions. Many firms list services but never write down how a service gets classified, so classification changes from one team to the next. Check that the methodology names the criteria, the decision owner and the record that proves each classification. Illustrative: a payment reconciliation service either passes the methodology or it does not, and the outcome should be traceable.

Policy never reviewed by the management body

Article 3 requires the management body to review the policy at least once a year. In practice the policy is approved once and then left unchanged while providers, locations and subcontractors change. Check the minutes for a dated annual review, a record of what changed, and a named role responsible for monitoring the arrangements.

Contracts that do not match the policy

Article 8 requires the contracts for these services to be written and to include the elements of DORA Article 30(2) and (3). Gaps appear when procurement signs standard terms that predate the policy. Fix this by mapping each policy requirement to a contract clause, then sampling existing contracts for the gaps and recording the remediation plan for each one.

Risk assessments that skip location and concentration

Article 5 requires a pre-contract risk assessment that covers data location, provider location and ICT concentration risk, alongside operational, legal, reputational and data protection risks. Assessments often cover the obvious risks and omit where data is stored and how many critical services depend on one provider or one cloud region. Check that each assessment records the storage regions, the provider's location, and the concentration of this provider across the register.

Assurance from a single source

Article 6 requires the policy to state how assurance on the provider is obtained, and to use more than one source where appropriate. Firms often rely only on a certificate or only on a questionnaire. A stronger approach combines the provider's independent audit reports, the firm's own audit rights and any appropriate certifications, with a dated record of which source covered which control.

Exit plans that exist only on paper

The policy must cover exit and termination, and an exit plan that has never been tested offers little protection if a provider fails. Check that each plan names the alternative provider or in-house option, the data that must be returned and in what format, and the steps and owners. Test the plan on a tabletop basis and record the findings and the updates made afterward.

Questions buyers ask about the DORA ICT services policy

How much effort does the DORA ICT services policy take to write?

The effort depends mainly on how many ICT services your entity runs, how many of them support critical or important functions, and how much contract and assurance evidence already exists. The policy itself must cover every phase of the contract lifecycle in Article 4 of Delegated Regulation (EU) 2024/1773, so the drafting is only part of the work. Most of the effort sits in building the methodology that decides which services are critical or important, then checking each in-scope provider against it. An entity with a short provider list and current contracts will spend far less than one with hundreds of undocumented cloud and software relationships. Ask any consultant to size the work from your service inventory and contract register, in writing, before agreeing scope.

How long does it take to produce and approve the policy?

No duration is fixed in the regulation, so the timeline is set by your own governance cycle and the state of your inventory. The policy must be reviewed by the management body at least once a year under Article 3, so the approval step is recurring, not a one-off event. Plan for drafting, business unit review, a risk assessment input, and a formal management body decision. Confirm with your competent authority how it expects to see the approval evidenced, and build the calendar around your board meeting dates rather than the drafting date.

What does the management body and business units need to contribute?

The management body carries accountability: it must approve the policy, review it at least once a year, and receive evidence that the arrangements are monitored. Business units must confirm which services they rely on and how those services support critical or important functions, because they hold the operational knowledge the ICT function cannot see alone. The policy also has to name the role or senior manager responsible for monitoring the arrangements, so that person needs time allocated and a clear mandate. Without these inputs, the methodology for classifying services tends to be written in isolation and then challenged during supervision.

Can a small firm write the ICT services policy internally?

A small firm can write it internally if it has someone who understands DORA, a short list of ICT providers, and the time to test the methodology against real contracts. The regulation does not exempt small entities from the policy content, so the proportionality question is about depth and documentation, not about skipping sections. Internal drafting is harder where the team lacks legal or contract review skills, since the policy must align with Article 30 contract requirements and the subcontracting rules. Many firms draft internally and bring in an outside reviewer for a gap check. Confirm with your competent authority how much documentation it expects from entities of your size.

What will an assessor ask for first?

Assessors typically start with the written policy, the evidence that the management body approved it and reviewed it in the last year, and the methodology used to decide which services support critical or important functions. They will then sample a few providers and ask for the pre-contract risk assessment, the due diligence record, and the assurance evidence the policy describes. Under Article 6, that assurance can come from your own audits, independent audit reports, provider internal audit reports, or appropriate certifications, so the policy must say which sources you use. Keep the register of information and contract files consistent with the policy, because mismatches are easy to spot. Confirm the exact supervisory request format with your competent authority.

Can a partner take over drafting the policy?

A partner can prepare the policy, the methodology, the contract lifecycle procedures and the evidence trail, working inside your environment and under your management body's decisions. The organization still owns the policy and must approve it, and only an independent auditor or assessor can issue any audit report or attestation. DeployOpen plans and documents self-hosted systems and prepares compliance evidence, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask any partner to show how the policy will be versioned, reviewed annually, and handed over so your team can maintain it after the engagement ends.

How does the ICT services policy relate to the register of information and subcontracting rules?

The policy is the governing document, while the register of information records the ICT third-party arrangements that the policy identifies, and the subcontracting rules in Delegated Regulation (EU) 2025/532 apply where a provider uses subcontractors for critical or important functions. The policy's methodology determines which arrangements must be flagged for register entries and enhanced contract terms. If the policy and register disagree on a provider's criticality, an assessor will question both. Maintain one inventory that feeds the policy review, the register templates under Implementing Regulation (EU) 2024/2956, and subcontracting approvals. Confirm the register submission format and timing with your competent authority.

Which documents should the policy link to for version history and evidence?

The policy should point to the documents that prove it is operating: the annual approval minutes, the service classification records, risk assessments, due diligence files, and exit plans. Open-source wikis such as XWiki keep page version history that records what changed, when and by whom, which helps show the annual review trail. Role-based permissions in BookStack can restrict who edits the policy while letting auditors read it. Both tools need configuration and access controls set by your team, so confirm they meet your own records and retention requirements before relying on them.

How DeployOpen prepares the ICT services policy evidence

DeployOpen helps financial entities and their technology teams prepare the working evidence behind an ICT services policy under Delegated Regulation (EU) 2024/1773. We scope the work in writing, build the policy evidence inside the client's own infrastructure with self-hosted open-source platforms, and hand over documentation the organization owns. The organization remains responsible for its policy, and only an independent auditor or competent authority assesses compliance.

How we scope

Engagements are fixed-scope, with the policy phases, business units and ICT services agreed in writing before work starts.
We confirm which ICT services support critical or important functions, using the methodology the client's policy sets out.
The scope names the contract lifecycle phases, the register of information links and the assurance sources to be covered.
Scope documents state which responsibilities stay with the client's management body, risk owners and compliance function.

How we build

We set up the policy document, review cycle and named monitoring role in a self-hosted wiki or knowledge base.
We prepare ex-ante risk assessment templates covering operational, legal, ICT, data and concentration risks.
We configure a self-hosted GRC platform so framework mappings and assessment records are held inside the client's environment.
Version history and role-based access are configured so approvals, reviews and changes are traceable.

How we hand over

Deliverables include the written policy set, templates, configuration records and an evidence index mapped to each Article 3 to 6 requirement.
We document how assurance on each provider is obtained, including own audits, independent reports and certifications where available.
Handover covers administrator training so the client can run annual reviews and monitoring without outside help.
Exit and termination procedures are documented as working records the client can test and update.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can update the evidence set when the policy is reviewed, a provider changes or a subcontractor is added.
Support scope is agreed in writing, so the client knows which annual review tasks we perform and which stay internal.
Before any external assessment, the client should confirm with its auditor or competent authority which evidence they expect.