DORA Vendor Assessment (2026 Guide)

M
By Matevž RostaherLast updated: May 27, 2026
dora-vendor-assessment-workspace-with-questionnaire-evidence-review-documents-an.jpg

You send a vendor questionnaire, wait two weeks, get half the answers back, and then realize the responses still do not tell you what you need to know. For many compliance, procurement, and risk teams, that is where the real DORA work starts. The form exists, the deadline exists, but the evidence is thin, ownership is unclear, and nobody feels fully confident signing off on the result.

That is exactly why a strong dora vendor assessment matters. Under the what is dora framework, financial entities need more than a generic supplier checklist. You need a structured way to assess ICT third-party arrangements, identify risk, document decisions, and support ongoing oversight. In 2026, that matters even more because regulators are moving from initial compliance toward proof that your controls operate in practice.

DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, turning complex regulatory requirements into structured, manageable workflows. In this article, you will learn what a practical DORA questionnaire should include, how to score vendor responses sensibly, and how to avoid the common mistakes that slow teams down.

  • What a DORA vendor assessment really covers
  • What a DORA vendor assessment should include (minimum outputs)
  • Why generic questionnaires usually fall short
  • What to include in your DORA questionnaire
  • DORA testing expectations: what to ask vendors about testing
  • How to review and score vendor responses
  • Risk assessment types and how they apply to vendor reviews under DORA
  • How this connects to your wider DORA records
  • A practical 2026 approach for lean teams
  • Frequently Asked Questions
  • What a DORA vendor assessment really covers

    A dora vendor assessment is not just a one-time form sent to a provider. It is part of a broader control process that helps you understand whether a third party supports critical or important functions, what ICT risks are involved, and whether the arrangement can be governed in a way that fits DORA expectations.

    Think of it this way. A useful assessment should help you answer five practical questions: what service is being provided, how important it is to your business, what dependencies exist, what controls the vendor has in place, and what residual risk remains after review. That is why the assessment sits so close to dora third party risk management.

    It is broader than procurement due diligence

    Many teams already run supplier onboarding or outsourcing reviews. Those are useful, but DORA raises the bar. Your dora provider assessment may need to support resilience, incident handling, concentration risk analysis, subcontracting visibility, and governance evidence, not just commercial or legal checks.

    From a regulatory standpoint, this also connects to the wider digital operational resilience act dora framework, which expects institutions to manage ICT dependencies in a structured and defensible way.

    What a DORA vendor assessment should include (minimum outputs)

    A lot of teams focus on the questionnaire, but regulators and internal auditors typically care just as much about what you produced at the end. If your process cannot generate a clear assessment record, you may end up with a folder of PDFs and email threads that do not add up to a decision you can defend.

    For most small compliance and risk teams, a practical approach is to define a minimum set of fields and outputs that every dora vendor assessment should produce, even for lower-risk providers. Then you can expand it for higher-risk services without reinventing the structure each time.

    A minimum viable assessment record

    In most cases, your final assessment record should include at least:

  • Vendor profile, including legal entity and relevant group context
  • Service scope, including what is in scope, what is out of scope, and where the service is delivered from
  • Criticality, including whether the service supports critical or important functions and the business impact if it fails
  • Key dependencies, including subcontractors, fourth parties, and any concentration or single points of failure you identified
  • Key risks, framed in plain language, for example loss of availability, data exposure, change-related outages, or incident notification delays
  • Controls and evidence reviewed, showing what you actually checked rather than what you were told
  • Residual risk conclusion, meaning what risk remains after considering the controls and evidence
  • Decision outcome, such as approve, approve with actions, or reject, plus who approved it and why
  • What many people overlook is that this record does not need to be long to be useful. It needs to be consistent, reviewable, and tied to evidence.

    Inputs that typically feed those outputs

    From a practical standpoint, most assessment records are built from three input streams:

  • Vendor questionnaire responses, including clarifications and follow-up answers
  • Internal context, such as your service tiering, data classification, architecture, and how the business uses the service in reality
  • Evidence sources, such as assurance reports, business continuity and disaster recovery artifacts, incident history, subcontractor lists, and independent testing summaries where appropriate
  • Those inputs should lead to a single documented assessment record that explains the conclusion. That is what turns a questionnaire into a decision process.

    Make the assessment reusable instead of stale

    One reason vendor assessments become painful is that the same provider gets assessed again and again, but each cycle starts from scratch. A simple fix is to treat your assessment like a living record with:

  • A named owner internally, so follow-ups do not disappear between teams
  • Versioning, so you can show what changed since the last review and why
  • A review date and reassessment trigger logic, so it is clear when and how oversight continues
  • A link to ongoing monitoring, for example tracking material incidents, scope changes, and subcontractor updates between annual reviews
  • This often keeps the process lighter over time. You are not trying to create a perfect one-off PDF. You are building an audit-friendly assessment trail that can support ongoing oversight.

    Why generic questionnaires usually fall short

    The reality is that many vendor forms are either too broad or too shallow. They ask for policies, certifications, and a few yes or no answers, but they do not help your team determine business impact, service criticality, or whether the vendor's control environment is adequate for your actual use case.

    A cloud storage provider supporting internal collaboration does not present the same risk profile as a core banking platform, payment processor, or outsourced claims system. Yet many institutions send both vendors the same questionnaire. That creates noise instead of clarity.

    Common problems in weak questionnaires

  • Questions are not tied to the actual service provided
  • Criticality is assumed, not assessed
  • Subcontracting risk is barely covered
  • Evidence requirements are unclear
  • Responses are collected, but not scored consistently
  • There is no clear link to what is ict risk in business terms
  • What many people overlook is that a dora questionnaire should support decision-making, not just data collection. If your reviewers cannot explain why a response is acceptable, needs remediation, or changes the vendor's risk rating, the process may look busy while still leaving important gaps.

    dora-provider-assessment-showing-tiered-vendor-review-and-ict-risk-classificatio.jpg

    What to include in your DORA questionnaire

    A strong dora vendor assessment questionnaire should be structured around the service, not around a random list of controls. In practice, that means collecting enough information to classify the arrangement, understand the provider's operating model, and evaluate resilience-related controls in context.

    Start with service and entity basics

    Begin with the fundamentals. Identify the legal entity, group relationship if relevant, service description, contract owner, data processed, delivery model, and geography. This is also where you determine whether the vendor should be treated as an dora ict service provider for the specific arrangement you are reviewing.

    These basics sound simple, but they often create major issues later if they are inconsistent across contracts, registers, and reporting files.

    Assess criticality and business impact

    Your questionnaire should ask which business process the service supports, whether it connects to critical or important functions, what the operational fallback options are, and how long the business could tolerate disruption. This turns abstract vendor information into decision-useful context.

    Consider this, two vendors may both have ISO certifications, but if one supports a customer-facing payment flow and the other supports an internal scheduling tool, your oversight approach should not be the same.

    Cover resilience and control areas that matter

    Most institutions will want questions across these areas:

  • Information security governance
  • Access management and authentication
  • Incident detection, escalation, and notification
  • Business continuity and disaster recovery
  • Data location, storage, and retention
  • Subcontracting and fourth-party dependencies
  • Change management and release practices
  • Audit rights, assurance reports, and independent testing
  • Termination support and exit planning
  • Under DORA, this means your dora questionnaire should also reflect the institution's need to monitor concentration and dependency risk over time, not only whether the provider has a policy document available.

    Platforms like DORApp streamline the Register of Information process through a five-step approach: importing existing data, managing it through an intuitive interface, auto-enriching from public sources, validating against rules, and generating compliant reports. That kind of structure can help if your questionnaire data needs to flow into wider oversight and reporting activities rather than remain stuck in email threads and spreadsheets.

    Ask for evidence, not only statements

    Here is the thing, self-declared answers are useful, but they should not be the end of the review. Ask for supporting documents where appropriate, such as security summaries, audit reports, business continuity test outputs, certifications, policy extracts, or subcontractor lists. You do not need every document from every vendor, but you do need enough evidence to support your assessment logic.

    DORA testing expectations: what to ask vendors about testing

    Testing is one of the areas where questionnaires often stay too high-level. Vendors say they test, but they do not explain what kind of testing, how often, what was in scope, or how findings are remediated. Under DORA, your oversight typically needs to go one step further, especially where a provider supports critical or important functions.

    Now, when it comes to the question people ask most, what are the tests under DORA, it helps to translate it into vendor-assessment language. You are usually not trying to collect every detailed report for every vendor. You are trying to confirm that the provider has a testing and improvement cycle that matches the risk of the service you rely on.

    Testing evidence you may want to see

    Depending on the service and your risk tiering, vendor evidence requests often include:

  • Resilience testing and reliability evidence, for example high-level availability testing approaches, failover design validation, and lessons learned from outages
  • Vulnerability management practices, including scanning cadence, patching expectations, and how urgent issues are handled
  • Incident response exercises, such as tabletop tests and post-incident reviews
  • Business continuity and disaster recovery testing, including frequency, outcomes, and recovery assumptions
  • Penetration testing summaries, which may be performed internally or by independent parties, depending on the vendor model
  • Remediation tracking, showing that findings turn into actions and are closed within reasonable timelines
  • Think of it this way. A one-page attestation that testing exists is rarely as useful as a short summary that shows cadence, scope, and how results drive improvements.

    Practical questions that keep testing reviews proportionate

    If you want testing coverage without drowning in documents, these questions tend to work well:

  • How frequently do you run BC and DR tests, and what are the last two test dates?
  • What was in scope for the last test cycle, and were there any material exclusions?
  • Are tests performed internally, independently, or as a mix, and how do you validate objectivity?
  • How do you track findings and remediation, and who signs off closure?
  • How do you communicate testing outcomes to customers, for example high-level summaries versus detailed reports under NDA?
  • For some vendors, especially larger providers, you may only receive customer-facing summaries. That can still be useful if it is consistent and detailed enough to support your residual risk conclusion.

    Tie vendor testing back to your oversight cadence

    Under DORA, institutions are expected to manage ICT risk and third-party dependencies in a way that fits their own operations. This often means aligning your vendor review cycle with what the provider actually tests and when material results are available. For higher-risk services, you may want to define how testing updates feed your oversight between annual reviews, for example by requesting periodic testing summaries or by linking reassessment triggers to material findings or outages.

    Regulatory requirements and supervisory expectations can vary by institution type and jurisdiction, so it is sensible to align these requests with your internal policies and, where needed, your legal or compliance teams. The point is to keep testing evidence practical, proportionate, and usable in your assessment record.

    How to review and score vendor responses

    Sending a questionnaire is the easy part. The harder part is deciding what the answers mean. A practical dora provider assessment usually combines vendor responses, internal context, and reviewer judgment. That means your methodology should be clear enough that two reviewers would reach similar conclusions from the same evidence.

    Use a review model that reflects real risk

    You do not need a perfect mathematical model. You do need a defensible one. In many cases, teams score responses across a handful of dimensions, such as service criticality, control maturity, incident readiness, subcontracting transparency, and recoverability. Each dimension can then influence an overall rating and any remediation actions.

    The goal is consistency, not false precision. A weighted model that your team understands is usually more useful than a complex scorecard that nobody trusts.

    Separate facts, gaps, and decisions

    One of the best ways to keep reviews defensible is to distinguish between:

  • Facts, what the vendor stated or evidenced
  • Gaps, what is missing, weak, or unclear
  • Decisions, what your institution accepted, escalated, or required to be remediated
  • This sounds obvious, but many teams mix all three together. Months later, nobody can tell whether a weak answer was accepted consciously, missed accidentally, or still waiting for follow-up.

    With features such as automated workflows, validation, a data model that converts to XBRL, and full-text search across records, DORApp is one example of a platform designed to help compliance teams keep that process structured and auditable. That matters most when several functions need to review the same provider, including compliance, risk, procurement, security, and business owners.

    dora-questionnaire-layout-for-vendor-assessment-with-structured-compliance-and-s.jpg

    Risk assessment types and how they apply to vendor reviews under DORA

    Teams often ask, what are the 4 types of risk assessment. In vendor assessments, the useful answer is less about textbook labels and more about which approach helps you reach a defensible conclusion for this provider, for this service, with your available time.

    For most institutions, the difference often comes down to four practical lenses you can apply during a dora vendor assessment. You can use one consistently, or combine them, as long as you document what you did and why.

    Qualitative vs quantitative

    A qualitative assessment uses structured judgment, for example low, medium, high ratings with clear definitions. A quantitative model uses numbers, weights, and calculations, sometimes with financial impact estimates.

    For most vendors, qualitative scoring is usually enough, especially if you define your thresholds clearly and tie them to evidence. A more quantitative approach can be useful for a small set of critical providers where you need to compare options, justify investment, or explain concentration decisions. The risk is that numbers can look objective even when the input assumptions are subjective.

    Inherent risk vs residual risk

    Inherent risk is the risk level before you consider controls. Residual risk is what remains after you consider controls, evidence, and mitigation actions.

    In vendor reviews, inherent risk often comes from the service profile, for example criticality, data sensitivity, customer impact, and reliance on subcontractors. Residual risk is where your questionnaire, evidence review, and remediation actions matter. Keeping the two separate helps you avoid the common problem where a strong control statement causes you to underestimate the risk of a high-impact service.

    Control-based (maturity) vs scenario-based (impact and outage)

    A control-based approach rates how mature the provider’s controls are, for example access management, change control, incident handling, BC and DR, and monitoring. A scenario-based approach asks what happens if a specific failure occurs, such as a regional outage, ransomware event, or loss of a critical subcontractor.

    Control maturity scoring is efficient and repeatable, which is why many teams use it as the baseline. Scenario thinking becomes important for critical services because it forces clarity on recoverability, communication timelines, and operational fallback options. In practice, teams often use a control scorecard for the questionnaire and add one or two scenarios for higher tiers.

    Common scoring pitfalls and how to avoid them

    Here is the thing, most scoring problems are not caused by the scale. They are caused by inconsistency. Common pitfalls include:

  • False precision, where a 3.7 score looks meaningful but does not reflect real evidence differences
  • Inconsistent thresholds, where one reviewer treats a missing document as minor and another treats it as critical
  • Undefined escalation, where a high-risk outcome does not trigger any clear approval step or remediation plan
  • A practical fix is to define review thresholds that trigger consistent actions, such as mandatory follow-up evidence, escalation to a risk committee, or a time-bound remediation plan before approval. This is especially relevant for providers supporting critical or important functions, where concentration risk, resilience expectations, and oversight cadence may need to be stricter than for low-impact vendors.

    How this connects to your wider DORA records

    A vendor assessment should not live in isolation. It should connect to contract data, service classification, internal ownership, and your Register of Information. If it does not, you may end up maintaining duplicate records and reconciling conflicting versions later.

    That is one reason many teams reviewing a dora vendor assessment also revisit their understanding of the dora regulation explained in operational terms, not just legal terms.

    Link assessments to the Register of Information

    If a provider supports ICT services relevant to DORA, the information gathered through your questionnaire may feed your Register of Information records, depending on your process design. That includes legal entity details, contract identifiers, service descriptions, geographic delivery data, and subcontracting details.

    From a practical standpoint, the assessment also helps you keep records meaningful. A register entry tells you what the arrangement is. A vendor assessment helps explain whether the arrangement is being governed appropriately.

    Keep the process alive after onboarding

    Too many institutions treat questionnaires as annual paperwork. In reality, your dora questionnaire process may need trigger events for reassessment, such as material incidents, major subcontracting changes, scope expansions, concentration concerns, or renewal cycles. That is part of the 2026 shift toward demonstrable resilience, where evidence of ongoing control matters more than a one-time collection exercise.

    If you want a broader view of related obligations, the ICT Risk Management category and articles like DORA Pillars Explained: Complete Breakdown (2026) can help place third-party reviews within the full DORA framework.

    A practical 2026 approach for lean teams

    If your team is small, the right answer is usually not a giant questionnaire with 200 questions. The right answer is a tiered approach. Start with core vendor data and business impact, then add deeper control questions where the service is critical, sensitive, or highly interconnected.

    A lean assessment workflow that usually works

  • Classify the service and provider
  • Determine business criticality
  • Send the right questionnaire version for that risk tier
  • Collect supporting evidence
  • Review responses across involved functions
  • Document findings, actions, and approvals
  • Set a reassessment trigger or review date
  • That is often more effective than sending every vendor the same oversized form. It respects your team's time and usually leads to better-quality answers from providers as well.

    DORApp's modular setup is relevant here because institutions can start with the pain point they need to solve first, such as Register of Information management or third-party risk workflows, instead of trying to redesign everything at once. If you are evaluating process tooling, you can explore more at DORApp Functions or see whether a trial fits your evaluation plan at Free Trial – 14 Days.

    For readers who want extra background on how DORA developed into its current form, DORA European Commission Timeline and History (2026) adds useful context. And if you are still aligning terminology internally, reading what is dora alongside your assessment design work can save time later.

    Disclaimer: The information in this article is intended for general informational and educational purposes only. It does not constitute professional technical, legal, financial, or regulatory advice. Website performance outcomes, platform capabilities, and business results will vary depending on your specific circumstances, goals, and implementation. Always evaluate tools and platforms based on your own needs and, where relevant, seek professional guidance.

    This article is for informational purposes only and does not constitute financial, legal, or regulatory advice. DORA compliance requirements may vary based on your institution type, size, and national regulatory framework. Content referencing regulated industries is provided for general context only and should not be interpreted as legal, regulatory, compliance, or financial advice. If you operate in a regulated sector, always consult qualified financial, legal, and compliance professionals for guidance specific to your situation.

    dora-vendor-assessment-scoring-and-evidence-review-process-for-third-party-risk-.jpg

    Frequently Asked Questions

    What is a DORA vendor assessment?

    A DORA vendor assessment is a structured review of an ICT third-party arrangement to understand the service provided, its importance to your business, the risks involved, and the controls the provider has in place. It usually includes a questionnaire, evidence review, internal analysis, and documented decisions. The point is not just to collect vendor statements. It is to help your institution assess operational resilience, governance, and dependency risk in a way that supports DORA-related oversight and ongoing monitoring.

    Is a DORA questionnaire mandatory for every vendor?

    Not necessarily in a uniform format. DORA expects financial entities to manage ICT third-party risk appropriately, but that does not mean every provider needs the same questionnaire. In practice, institutions often apply a risk-based model. Lower-impact vendors may receive a shorter assessment, while providers supporting critical or important functions usually require deeper review. The key is to be able to explain your methodology, show consistency, and demonstrate that your process is proportionate to the service and risk involved.

    What should a DORA provider assessment ask about subcontractors?

    Your assessment should usually ask whether the provider relies on subcontractors to deliver any part of the ICT service, where those parties operate, what activities they perform, and how the primary vendor oversees them. You may also want to know whether material changes in subcontracting trigger notification or approval rights under the contract. In 2026, subcontracting oversight has become more important because regulators increasingly expect institutions to understand supply chain dependencies, not just their direct contractual counterpart.

    How long should a DORA questionnaire be?

    There is no ideal page count. A better question is whether the questionnaire helps you reach a defensible risk conclusion. For many institutions, a tiered structure works best. A short core questionnaire captures legal entity, service, criticality, and key control facts. Then additional sections can be triggered for higher-risk services. That usually leads to better completion rates and more relevant answers than a huge one-size-fits-all questionnaire. If every provider receives the same long form, your reviewers may spend more time filtering noise than understanding risk.

    How often should vendor assessments be repeated under DORA?

    That depends on your internal policy, vendor criticality, and trigger events. Annual reassessment is common, but not always sufficient by itself. In many cases, you should also reassess after major incidents, contract renewals, significant service changes, new subcontracting chains, or material control issues. The important point is that your process remains active. DORA oversight is moving toward proof that institutions can monitor third-party arrangements continuously, not just produce static records once a year.

    What evidence should vendors provide with questionnaire responses?

    Evidence should match the level of risk and the claims being made. Common examples include audit reports, certifications, business continuity summaries, incident management procedures, security policy extracts, architecture or hosting summaries, and subcontractor information. You do not always need full policy packs. Often, targeted evidence is more useful. What matters is whether your team can support the final assessment with enough documentation to explain why a response was accepted, challenged, or followed up through remediation.

    How does a DORA vendor assessment relate to the Register of Information?

    The two processes are closely related, but they are not identical. The Register of Information records the institution's ICT third-party arrangements in a structured format for governance and reporting purposes. A vendor assessment helps evaluate the quality, resilience, and risk profile of a specific arrangement. Some data points may overlap, such as provider identity, service details, and subcontracting information. Still, the assessment adds context, review logic, and decision evidence that a register entry alone would not usually provide.

    Who should review DORA questionnaire responses internally?

    That usually depends on the service type and your governance model, but reviews often involve a combination of procurement, compliance, risk, information security, legal, and the business owner. Critical services typically need broader review because the questions touch more than one discipline. A practical model assigns clear ownership for each review area and defines who approves the final result. This reduces the common problem where several teams comment informally, but nobody is clearly responsible for the final assessment decision.

    Can software automate the DORA vendor assessment process?

    Software can support the process, especially where you need repeatable workflows, data validation, evidence tracking, and audit trails. It may help with sending questionnaires, collecting responses, scoring results, triggering reviews, and linking outputs to wider DORA records. Still, automation does not remove the need for expert judgment. A good platform should make the work more structured and less manual, while keeping human review where policy interpretation, risk acceptance, and escalation decisions are required.

    What is the biggest mistake institutions make with DORA assessments?

    The biggest mistake is often treating the questionnaire as the objective instead of the tool. If your process ends once the vendor submits answers, you may miss weak evidence, unclear dependencies, or unresolved control gaps. Another common issue is using the same assessment for every provider regardless of service criticality. A useful DORA assessment process should help your team understand the arrangement, challenge inconsistent responses, and document defensible decisions that stand up over time.

    What is a vendor assessment?

    A vendor assessment is a structured review of a third party you rely on, usually to understand what service they provide, how the service is used internally, what risks it introduces, and whether the vendor’s controls are strong enough for your needs. In a DORA context, the assessment typically focuses on ICT and operational resilience, meaning it looks at security, incident readiness, resilience, subcontracting dependencies, and your ability to oversee and exit the arrangement in a controlled way.

    What are the 4 types of risk assessment?

    In vendor reviews, the four most practical risk assessment types are: qualitative versus quantitative scoring, inherent versus residual risk analysis, control-based (maturity) assessment, and scenario-based (impact and outage) assessment. Many teams use a qualitative, control-based model for most providers, then add scenario thinking and tighter thresholds for critical services. What matters is that your approach is consistent, proportionate, and documented so your conclusions can be explained later.

    What are the tests under DORA?

    DORA places strong emphasis on operational resilience testing, and vendor assessments often ask providers about the testing they perform that supports service reliability and security. In practice, this may include business continuity and disaster recovery tests, incident response exercises, vulnerability management routines, and penetration testing summaries. The right level of detail typically depends on the service criticality and how your institution relies on the provider, so many teams request high-level summaries for lower tiers and more specific evidence for critical services.

    What are the 5 things a risk assessment should include?

    A practical risk assessment record typically includes: scope, meaning what service and usage are being assessed, context and criticality, meaning why it matters and what impact disruption could cause, key risks and dependencies, including subcontractors and single points of failure, controls and evidence reviewed, showing what reduces risk in practice, and a residual risk conclusion with a documented decision, such as approval, approval with actions, or rejection. The goal is to make the assessment traceable, not just to assign a score.

    Key Takeaways

  • A dora vendor assessment should support risk decisions, not just collect vendor answers.
  • The best dora questionnaire structure is usually service-based and risk-tiered, not identical for every provider.
  • Evidence, review logic, and documented decisions matter as much as the questionnaire itself.
  • Vendor assessments should connect to your Register of Information and wider ICT risk processes.
  • In 2026, institutions need to show ongoing oversight, not only one-time compliance activity.
  • Conclusion

    If your current vendor questionnaire feels too generic, too manual, or too disconnected from the rest of your DORA process, you are not alone. Most teams do not struggle because they lack questions. They struggle because the process around those questions is unclear. A useful dora vendor assessment gives you a practical way to classify services, gather relevant evidence, involve the right reviewers, and document decisions that still make sense months later.

    Now, when it comes to improving that process, the smartest next step is usually not to add more fields. It is to tighten the structure, align it with business criticality, and connect it to your ongoing third-party oversight model. If you want to see how a modular platform approaches that challenge, DORApp is worth exploring at Book a Demo. You can also explore more practical DORA guidance through the Dorapp blog and related categories to keep building a cleaner, more defensible compliance workflow.

    M

    About the Author

    Matevž Rostaher is Co-Founder and Product Owner of DORApp. He brings deep experience in building secure and compliant ICT solutions for the financial sector and is positioned by DORApp as an expert trusted by financial institutions on complex regulatory and operational challenges. DORApp’s own webinar materials list him as CEO and Co-Founder of Skupina Novum d.o.o. and CEO and Co-Founder of FJA OdaTeam d.o.o. His articles should carry the voice of someone who understands not just compliance requirements, but the systems and delivery realities behind them.