DORA has applied since 17 January 2025. So the question from your board, your internal auditors and the Central Bank isn't really "are you ready?" anymore. It's "show us it works."
You need ICT risk management, incident handling, resilience testing and third-party controls that are in place, actually operating, and backed by evidence you can put on the table. We assess where you really stand, test whether the controls hold up, find the gaps that matter and help you build a remediation plan your management body can own.
21+ years
in security audit and assurance, since 2004
CREST
accredited security testing
ISO 27001
certified ourselves
Vendor-neutral
no product sales, no outsourcing
Where things stand in 2026
The Digital Operational Resilience Act is an EU regulation, so it applies directly in Ireland. No transposition, no Irish version. It's been in application since 17 January 2025, and it's filled out by a stack of regulatory and implementing technical standards (RTS and ITS) adopted by the European Commission, plus guidance and Q&As from the EBA, EIOPA and ESMA.
For the financial entities it regulates, the Central Bank of Ireland is the competent authority. In practice that means it receives your major ICT-related incident reports and your Register of Information through the Central Bank Portal, it uses its ICT Self-Assessment Tool (ICT-SAT) to tailor supervision, and it handles advanced threat-led penetration testing through TIBER-IE.
The Central Bank has been fairly blunt about expectations. Most of the technical standards have been in place since January 2025, the RTS on subcontracting was finalised in July 2025, and it says the work firms are doing to close gaps in their frameworks, policies and processes should by now be substantially complete.
So the useful question for you isn't whether you've got a DORA policy. It's whether the controls behind it actually run, whether someone can prove it, and whether the gaps you already know about are being closed on a timeline your management body has signed off.
Scope first
Not every company in Ireland is caught by DORA, and not every firm that is caught has the same obligations. DORA sets out who's in scope in Article 2, then scales the requirements by size, risk profile and the complexity of what you do. There are really three different positions you can be in.
LAYER 1 · DIRECTLY IN SCOPE
Article 2(1)(a)–(t)
Supervised in Ireland by the Central Bank. The categories include:
Credit institutions · payment institutions (including exempted ones) · account information service providers · e-money institutions (including exempted ones) · investment firms · crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens · central securities depositories · central counterparties · trading venues · trade repositories · AIFMs · UCITS management companies · data reporting service providers · insurance and reinsurance undertakings · insurance, reinsurance and ancillary insurance intermediaries · IORPs · credit rating agencies · administrators of critical benchmarks · crowdfunding service providers · securitisation repositories
Watch the carve-outs. Article 2(3) excludes, for example, small AIFMs under Article 3(2) AIFMD, small insurers exempt under Article 4 Solvency II, IORPs with no more than 15 members and insurance intermediaries that are micro, small or medium-sized. Microenterprises get lighter treatment, and some entities use the simplified ICT risk management framework in Article 16.
LAYER 2 · MOSTLY INDIRECT
Articles 28–30 via your customers
If you're a cloud, software, data or managed service provider selling into financial entities, DORA reaches you mostly through your customers. They have to run due diligence on you, record you in their Register of Information, put specific clauses in your contract (audit and access rights, incident assistance, exit, and for critical or important functions, TLPT cooperation) and monitor you over time.
Being a supplier to a regulated firm doesn't, on its own, put you under Central Bank DORA supervision. But you'll feel the requirements in every contract renewal and due diligence questionnaire.
LAYER 3 · EU OVERSIGHT
Articles 31–44
A small group of providers is designated as critical by the European Supervisory Authorities and overseen directly by a Lead Overseer (EBA, EIOPA or ESMA). The first list of 19 CTPPs was published on 18 November 2025, built from the data in firms' Registers of Information.
One thing people miss: using a CTPP doesn't hand off your responsibility. You still have to manage the risk of that arrangement yourself.
Why we confirm scope before we assess anything. A group with a bank, a payment institution and an in-house ICT services company has three different DORA positions under one roof. Getting scope, entity category and proportionality right first changes which articles apply, how deep testing needs to go and what "good" evidence looks like. It also stops you paying for work you don't need.
Assessment
A DORA compliance assessment for Irish financial entities is a structured, evidence-based look at how your organisation measures up against the Regulation and the technical standards that apply to you. We look at what's documented, what's actually happening, and the distance between the two.
A quick example of the kind of thing we find. A firm had a solid business continuity policy and an annual DR test on the calendar. The test ran every year. What it didn't do was restore the system that supports their most important customer-facing function, because that system sat with a SaaS provider that wasn't in the test plan. On paper, compliant. In practice, the one recovery that mattered most had never been tried.
Consulting
Finding gaps is only half the job. Our DORA consulting work in Ireland is about closing them: sitting with your risk, ICT, security and procurement people and getting controls working and evidenced. A good DORA consultant should leave you more capable, not more dependent, so we work alongside your team rather than around it.
Running ISO 27001, SOC 2 or NIS2 alongside DORA? Our AuditFusion360 approach maps overlapping controls once, so you're not collecting the same evidence three times. Our DORA to ISO 27001 and SOC 2 mapping guide shows how that works.
Audit
"DORA audit" gets used to mean a few different things, so let's be precise about what we offer. Our DORA audit services in Ireland are an independent, evidence-based evaluation of your controls against DORA and the applicable technical standards. We test design, implementation and, where the scope includes it, operating effectiveness, and you get a findings report you can act on and share with your board and internal audit.
It's commissioned by you, for your own assurance. That's valuable. But it isn't the same thing as the internal audit that DORA itself requires, and it isn't a certificate.
A DORA compliance audit from us is not:
| Gap / readiness assessment | DORA compliance audit (commissioned) | Internal audit under Article 6(6) | |
|---|---|---|---|
| Purpose | Find gaps and plan remediation | Independent view on whether controls meet DORA and work | Regular audit of the ICT risk management framework, in line with your audit plan |
| Who drives it | Compliance, risk or the DORA programme | Management, the board or a committee | Your internal audit function under its audit plan |
| Testing depth | Design and documentation, some walkthroughs | Design, implementation and operating effectiveness testing | Set by the audit plan, commensurate with ICT risk |
| Output | Gap register and roadmap | Findings report with prioritised observations | Audit report, then formal follow-up of critical ICT findings (Article 6(7)) |
| Meets Article 6(6) on its own? | No | Not automatically. Your audit function decides whether and how to rely on it | This is the requirement |
Control design, implementation and operating effectiveness across your ICT risk framework, policies, incident processes, third-party risk and resilience testing, plus the quality of the evidence behind each one. If you've already had audit findings, we'll check whether earlier remediation actually closed them, not just whether the tracker says "done".
Where your internal audit team wants specialist ICT and DORA input, we can talk about how our work fits your audit plan. Whether that meets the knowledge, skills and independence tests in Article 6(6) is your audit function's call, and we'll respect it. And if we helped design a control, we'll say so and recommend someone independent tests it.
Critical — a critical or important function is exposed, or a core DORA obligation isn't being met
High — a control exists but doesn't operate reliably, or evidence can't be produced
Medium — partial coverage or documentation that doesn't match practice
Low — improvement opportunities and hygiene points
Gap & readiness
A DORA gap assessment (some people call it a readiness assessment, even now that DORA is live) is the fastest way to find out where you're exposed. In 2026 it's most useful after a restructure, a new authorisation, a big outsourcing change, or when you simply don't trust the picture your last programme left behind. Here's how we run one.
01
Entities, entity types, critical or important functions, proportionality.
02
DORA articles plus the RTS and ITS that apply to you.
03
Interviews and walkthroughs with the people who run them.
04
Records, logs, tickets, test results, minutes. Not just the policy.
05
Missing controls, controls that don't operate, and evidence gaps.
06
Ranked by impact on critical functions and regulatory exposure.
07
Owners, dependencies, dates and effort, ready for sign-off.
08
Retest what was fixed so closure means closed.
Want the detail behind each step? Read our walkthrough on how to run a DORA gap assessment properly.
Chapter II · Articles 5–16
This is the backbone of DORA. Your management body carries ultimate responsibility for ICT risk (Article 5), and needs a documented ICT risk management framework that's reviewed at least once a year and after major incidents (Article 6, for firms other than microenterprises). The detail sits in Commission Delegated Regulation (EU) 2024/1774, which also sets out the simplified framework for eligible smaller entities.
Identify
Art. 8 · ICT and information assets, dependencies, legacy systems, risk sources
Protect & prevent
Art. 9 · access, change, patching, encryption, network security
Detect
Art. 10 · anomalous activity, alert thresholds, monitoring
Respond & recover
Art. 11 · ICT business continuity policy, response and recovery plans
Backup & restore
Art. 12 · backup policies, restoration, recovery methods
Learn & evolve
Art. 13 · post-incident reviews, training, continuous improvement
Communicate
Art. 14 · crisis communication plans, internal and external
What we actually check: roles and responsibilities, and whether the control function has real independence. Whether your asset inventory matches what's running. Whether the dependencies behind each critical or important function are mapped, including the SaaS and outsourced bits. Whether backups are restored in tests, not just taken. And whether lessons from incidents change anything.
A DORA compliance service can evaluate implementation and help you improve it. It doesn't take over your management body's responsibility, and we'd be wary of anyone who says it does.
Related service
Need a deeper look at supplier-side ICT risk? See our vendor and third-party risk assessment service.
Chapter III · Articles 17–23
DORA wants a defined process to detect, manage and log ICT-related incidents (Article 17), classify them against set criteria (Article 18) and report the major ones to your competent authority (Article 19). In Ireland, since 17 January 2025, those reports go to the Central Bank through its Portal, using templates designed by the ESAs. Credit institutions, payment and e-money institutions and account information service providers also report major operational or security payment-related incidents under DORA now.
Detect & log
Early warning indicators, logging, ownership
Classify
Criteria and thresholds in RTS (EU) 2024/1772
Escalate
Senior management and management body informed
Initial notification
Within 4 hours of classifying as major, and no later than 24 hours after becoming aware
Intermediate report
Within 72 hours of the initial notification
Final report
Within one month of the latest intermediate report
Post-incident review
Root cause, lessons learned, control changes
Time limits: Commission Delegated Regulation (EU) 2025/301. Templates: Implementing Regulation (EU) 2025/302. Always follow the Central Bank's current reporting guidance for the live process.
Where it usually breaks: the classification call. Teams know how to fight a fire, but nobody's sure who decides it's "major", the clock starts before anyone looks at the thresholds, and the Portal login belongs to someone on leave. We test the whole chain with realistic tabletop scenarios, check the documentation and evidence it leaves behind, and review how post-incident actions get closed. Significant cyber threats can also be notified voluntarily, and we'll help you decide when that's worth doing.
Chapter IV · Articles 24–27
DORA's testing rules come in two tiers, and mixing them up is one of the most common misunderstandings we see. Every in-scope firm (other than microenterprises) needs a proper testing programme. Only a much smaller group, identified by the authority, has to do advanced threat-led penetration testing on top.
TIER 1 · ARTICLES 24–25
Risk-based and proportionate. Tests are carried out by independent parties, internal or external. All ICT systems and applications supporting critical or important functions need appropriate testing at least yearly.
Can include vulnerability assessments and scans, open-source analysis, network security assessments, gap analyses, physical security reviews, source code reviews, scenario-based tests, compatibility, performance and end-to-end testing, and penetration testing.
TIER 2 · ARTICLES 26–27
Only for financial entities identified by the competent authority. At least every three years, on live production systems, covering several or all critical or important functions.
Microenterprises and firms on the simplified framework aren't required to do TLPT.
For the tier 1 programme, our CREST-accredited penetration testing team can scope and report tests against the DORA evidence you need, and we'll help design the wider programme around your critical functions.
Ireland-specific
Threat-led penetration testing is an intelligence-driven red-team exercise that imitates the tactics of real threat actors against live production systems supporting your critical or important functions. It's governed by Articles 26 and 27 of DORA and by Commission Delegated Regulation (EU) 2025/1190, the RTS on TLPT.
In Ireland, TLPT runs through TIBER-IE, the Central Bank's implementation of the TIBER-EU framework. The ECB updated TIBER-EU in February 2025 to line up with the DORA RTS, so the process, deliverables and terminology now match. Purple-teaming is mandatory, for instance, and the old "White Team" is now the "Control Team".
Who's in scope? The Central Bank engages directly with firms that are, and runs an identification exercise every year. If you haven't been contacted, you're very likely not required to do TLPT right now, though that can change as the annual exercise is repeated. TLPT queries go to TIBER-IE@centralbank.ie.
How we can help, honestly
| Standard penetration test | TLPT under DORA / TIBER-IE | |
|---|---|---|
| Who needs it | Most in-scope firms, as part of their testing programme | Only firms identified by the authority |
| Driven by | An agreed scope of assets or applications | Threat intelligence about real actors targeting you |
| Environment | Often test or staging, sometimes production | Live production systems supporting critical or important functions |
| Who knows | IT and security teams usually aware | Covert: only a small Control Team knows |
| Authority involvement | None | Central Bank / TIBER-IE team oversees the test |
| Frequency | Set by your risk-based programme | At least every three years, unless the authority says otherwise |
Chapter V · Articles 28–30
Irish financial services lean heavily on cloud platforms, fund administration technology, outsourced ICT and group service companies. DORA treats all of that as ICT third-party risk and expects you to manage it across the whole lifecycle, with extra rigour where a service supports a critical or important function. Intra-group providers count too.
1 · Strategy
ICT third-party risk strategy and policy, approved by the management body
2 · Inventory
Every ICT supplier, service and subcontractor chain
3 · Pre-contract
Risk assessment, due diligence, conflicts of interest, concentration risk
4 · Contract
Article 30 clauses; more for critical or important functions
5 · Monitor
Performance, incidents, audit rights, subcontracting changes
6 · Exit
Tested exit strategies, termination rights, transition periods
Where firms usually struggle: subcontracting chains nobody fully mapped, contracts that predate DORA and still lack the Article 30 provisions, "critical or important" labels applied inconsistently across the group, and exit plans that exist as a paragraph rather than something anyone has walked through. The RTS on subcontracting, finalised in 2025, raised the bar on the first of those.
We review the strategy, the inventory, due diligence records, a sample of contracts against Article 30, concentration analysis and exit planning, and we can run the supplier-side assessments themselves.
Three positions, three different obligations
You're a financial entity: you own the risk and all of Articles 28–30, whoever your provider is.
You're an ICT provider: you meet DORA through customer contracts, due diligence and audit rights.
You're a designated CTPP: you're overseen directly by a Lead Overseer under Articles 31–44.
Article 28(3) · Ireland-specific
Every in-scope financial entity has to keep a Register of Information (RoI) covering all its contractual arrangements for ICT services from third-party providers, with more detail for those supporting critical or important functions. The format is set by Implementing Regulation (EU) 2024/2956. And it isn't just an internal record: the ESAs used firms' registers to designate the first CTPPs.
In Ireland you submit it through the Central Bank Portal. For the 2026 collection the window ran from 2 to 31 March 2026, with data as at 31 December 2025. The EBA then added a data-quality review in April 2026, which could trigger resubmission. Check the Central Bank's RoI page for the next window rather than assuming it'll repeat.
It's not a spreadsheet, either. It's a zipped xBRL-CSV (OIM) reporting package following EBA DPM 4.0. Your entity needs a valid LEI, your ICT providers need a valid LEI or EUID (or another permitted code for third-country providers), and there's no official conversion tool.
Where registers go wrong
Supplier identification
LEI / EUID checks, group structures
Contract & service mapping
Contracts to services to functions
Criticality
Consistent critical or important calls
Data quality
Pre-submission validation
Ownership & updates
Kept current through the year
We help you build, clean and validate the register data before submission. The upload and sign-off on the Portal stay with your authorised users.
How we work
DORA isn't a project with an end date. Suppliers change, systems change, the Central Bank's collections come round again. This is the cycle we use, and step 13 feeds straight back into step 2.
01 · FOUNDATION
Confirm DORA scope
02 · FOUNDATION
Establish current state
03 · FOUNDATION
Map applicable requirements
04 · ASSESS
Assess ICT risk framework
05 · ASSESS
Review incident processes
06 · ASSESS
Assess resilience testing
07 · ASSESS
Map ICT third parties
08 · ASSESS
Validate Register of Information
09 · ASSESS
Review evidence
10 · ACT
Identify gaps
11 · ACT
Prioritise remediation
12 · ACT
Validate improvements
13 · SUSTAIN ↻
Establish ongoing monitoring
↻ Monitoring outputs (new suppliers, incidents, test results, audit findings, Central Bank updates) loop back into step 2.
Evidence
Most DORA findings we raise aren't "you don't have a control." They're "you couldn't show us it works." Good evidence is generated as a by-product of doing the work, has a named owner, and can be found quickly by someone who didn't create it.
Control operates
Evidence created as the work happens
Owner confirms
Complete, dated, attributable
Stored & indexed
Mapped to the DORA requirement
Reviewed
Second line or assessor sampling
Audit-ready
Retrievable on request
ICT risk management framework · policies · management body minutes and approvals · management reporting · training records
ICT risk assessments · asset and information asset inventories · dependency maps · legacy system reviews
Incident and classification records · reports submitted · post-incident reviews · business continuity plans · backup and restore test results
Testing plans and results · remediation evidence · third-party risk assessments · contracts · Register of Information · audit findings and tracking
Not every item applies to every firm. What you need depends on your entity type, size and proportionality position, which is exactly why we confirm scope first.
At a glance
| DORA area | What it covers | Questions to ask | Potential evidence | How VISTA Infosec can support |
|---|---|---|---|---|
| Governance | Management body responsibility for ICT risk (Art. 5) | Does the board approve and review the framework? Is ICT risk reported to it? | Minutes, approvals, reporting packs, role definitions | Governance review, management reporting design |
| ICT risk management | Framework, identification, protection, detection, response, recovery (Art. 6–16) | Is the framework reviewed yearly? Does the asset inventory match reality? | Framework document, risk assessments, inventories, BCP and restore tests | Framework assessment, ICT risk assessment, control testing |
| Incident management | Detection, classification, major incident reporting (Art. 17–23) | Who decides "major"? Could you meet the reporting time limits? | Incident log, classification records, reports, post-incident reviews | Process review, tabletop exercises, template readiness |
| Resilience testing | Risk-based testing programme (Art. 24–25) | Are systems supporting critical functions tested at least yearly? By independent testers? | Test programme, plans, results, remediation evidence | Programme design, CREST-accredited penetration testing |
| TLPT | Advanced testing for identified firms (Art. 26–27, RTS 2025/1190) | Has the Central Bank identified us? Are critical functions mapped to systems? | Central Bank correspondence, scoping docs, remediation plans | Readiness, remediation and retesting; roles confirmed case by case |
| Third-party ICT risk | Strategy, due diligence, contracts, exit (Art. 28–30) | Do contracts include Article 30 clauses? Are exit plans realistic? | Strategy, due diligence files, contracts, exit plans, concentration analysis | TPRM review, supplier assessments, contract gap analysis |
| Register of Information | All ICT contractual arrangements (Art. 28(3), ITS 2024/2956) | Would our register pass EBA data-quality checks? Who owns it? | RoI package, validation feedback, update log | Data build, cleansing and pre-submission validation |
| Audit & review | Internal audit of the ICT risk framework (Art. 6(6)–(7)) | Is ICT audited regularly, by people with the right skills and independence? | Audit plan, audit reports, auditor qualifications | Independent DORA compliance audit; audit support where your audit function chooses |
| Remediation | Follow-up of critical ICT audit findings (Art. 6(7)) | Are findings verified as closed, not just marked closed? | Findings tracker, closure evidence, retest results | Remediation planning, closure validation, retesting |
Article 6(6) and 6(7)
DORA requires the ICT risk management framework of financial entities, other than microenterprises, to be subject to internal audit by auditors on a regular basis, in line with the firm's audit plan. Those auditors need sufficient knowledge, skills and expertise in ICT risk, and appropriate independence. The frequency and focus of ICT audits should match the firm's ICT risks.
Based on what internal audit finds, firms must have a formal follow-up process, including rules for timely verification and remediation of critical ICT audit findings.
To be clear about where we fit: our DORA compliance audit and assessment work can give your board and your internal audit function an independent, specialist view. It doesn't replace your own internal audit function, and whether your audit plan relies on it is a decision for your audit committee.
Coverage
We support organisations operating across Ireland, whether that's a bank or fund manager in Dublin, a payments or insurance operation in Cork, or ICT and service teams in Galway, Limerick or Waterford. Plenty of Irish firms also sit inside wider EU groups, and we're used to working across entities and jurisdictions at once.
Our EU engagements are led from our German base and contracted through Zulon Audits OÜ, our entity in Tallinn, Estonia. Most assessment work runs remotely through a secure evidence portal, with on-site sessions agreed at scoping where the work needs them. We don't have an Irish office, and we'd rather tell you that up front.
WORKING WITH TEAMS IN
Dublin · Cork · Galway
Limerick · Waterford
and wherever else your Irish-regulated entities operate.
Organisations inside DORA's scope or its ecosystem. Obligations differ by category, size and proportionality, so being on this list doesn't mean identical requirements.
Why us
Since 2004 our work has been evidence-based assessment: PCI DSS as a QSA, ISO 27001, SOC 2 and more. That habit of asking "show me" is exactly what DORA now demands.
CREST-accredited penetration testing and red-team capability sit alongside our compliance teams, so testing evidence and control findings line up.
We don't resell tools, and we don't hand your critical assignments to subcontractors.
If you're dealing with ISO 27001, SOC 2 or NIS2 as well, we map controls once and reuse evidence where the requirements genuinely overlap.
Verifiable credentials
What we won't claim: that we're approved by the Central Bank (it doesn't approve DORA consultants), that DORA has a certificate, or that any provider can guarantee compliance.
Pricing
We don't publish a fixed price, because a single-entity payment institution and a multi-entity insurance group aren't the same job. What we will do is scope it properly and give you a fixed, written proposal. These are the things that move the number:
FAQ
DORA is the Digital Operational Resilience Act, Regulation (EU) 2022/2554. It sets harmonised rules for how EU financial entities manage ICT risk, handle and report ICT-related incidents, test their digital operational resilience and manage ICT third-party risk, and it creates an EU oversight framework for critical ICT third-party service providers. It has applied since 17 January 2025.
Yes. DORA is an EU regulation, so it applies directly in Ireland without national transposition. The Central Bank of Ireland supervises compliance for the financial entities it regulates and receives major ICT-related incident reports and Registers of Information through the Central Bank Portal.
The financial entities listed in Article 2 of DORA, for example credit institutions, payment and e-money institutions, investment firms, AIFMs and UCITS management companies, insurers and reinsurers, in-scope insurance intermediaries, crypto-asset service providers authorised under MiCA and market infrastructures. Some smaller entities are excluded and others follow a lighter, proportionate regime. ICT providers are mostly affected through their customers' contracts unless they are designated as critical.
A DORA consultant helps you work out which requirements apply, assesses your current controls and evidence against them, and supports you in closing the gaps. That can include framework and policy work, third-party risk and Register of Information support, incident process design, resilience testing strategy and remediation planning. Responsibility for compliance stays with your management body.
A DORA gap assessment identifies where your framework, controls and evidence fall short of the requirements and produces a prioritised remediation roadmap. A DORA compliance audit is a more formal, independent evaluation that tests whether controls are designed, implemented and operating effectively, and reports findings. Neither is a certification, and a commissioned audit does not automatically satisfy DORA's internal audit requirement.
Yes, for financial entities other than microenterprises. Article 6(6) requires the ICT risk management framework to be subject to internal audit on a regular basis, in line with the audit plan, by auditors with sufficient ICT risk knowledge, skills, expertise and appropriate independence. Article 6(7) requires a formal follow-up process for the timely verification and remediation of critical ICT audit findings.
No. DORA is a regulation, not a certification standard, and there is no official DORA certificate. An assessment or audit report can evidence your position to your board, auditors or customers, but compliance is assessed by your competent authority, which in Ireland is the Central Bank for the entities it regulates.
It is the register every in-scope financial entity must keep of all its contractual arrangements for ICT services provided by ICT third-party service providers, under Article 28(3). The format is set by Implementing Regulation (EU) 2024/2956. Irish financial entities submit it to the Central Bank through the Central Bank Portal as an xBRL-CSV reporting package during the collection window the Central Bank announces.
No. Threat-led penetration testing is only required of financial entities identified by the competent authority under Article 26. In Ireland the Central Bank engages directly with firms in scope and carries out an identification exercise annually. Microenterprises and entities on the simplified ICT risk management framework are not required to perform TLPT. Every other in-scope firm still needs a risk-based resilience testing programme.
TIBER-IE is the Central Bank of Ireland's implementation of the TIBER-EU framework for threat intelligence-based ethical red teaming. It is the route through which DORA threat-led penetration testing is run for identified Irish financial entities. TIBER-EU was updated in February 2025 to align with the DORA technical standards on TLPT.
It depends on scope. The main factors are your entity type, the number of legal entities, the size of your ICT environment, how many ICT suppliers you rely on, the complexity of your Register of Information, documentation maturity, the depth of testing and how much remediation support you need. We scope each engagement and provide a fixed written proposal.
Yes. We support organisations operating across Ireland, including teams in Dublin, Cork, Galway, Limerick and Waterford. EU engagements are led from our German base and contracted through Zulon Audits OÜ in Tallinn, Estonia. Most work runs remotely through a secure evidence portal, with on-site sessions agreed where needed. We do not have an Irish office.
Expert Auditors. Faster Certification.
European Operations
European engagements are delivered through Zulon Audits OÜ, the European practice of VISTA InfoSec.
Visit Zulon Audits →
VISTA InfoSec LLC,347 Fifth Ave,
Suite 1402-526, New York, NY 10016
© Copyright 2026. VISTA InfoSec. All Rights Reserved. | Disclosure Policy | Privacy Policy | Sitemap
Enquire Now