What DORA Article 4 proportionality asks financial entities to show
Article 4 scales Chapter II of DORA by size, overall risk profile, and the nature, scale and complexity of an entity's services, activities and operations. Chapters III (incidents), IV (testing) and Section I of Chapter V (ICT third-party risk) are applied proportionately only where their own articles say so. For a compliance lead or CIO, the first decision is therefore which entity-level facts drive the scaling, and then which specific rules in each chapter the entity may apply in lighter form. The principle exists to prevent two failures: over-engineering, where a small firm builds a programme sized for a global bank and spends resources that do not reduce its risk, and under-protecting, where a firm that is large or complex treats itself as small and leaves critical services with thin controls. Both failures become visible in the same place, the ICT risk management framework and its annual review report. The principle is hard to document because it asks for judgment, and judgment is only credible when the reasoning is written down. Article 4(3) tells competent authorities to consider how an entity applied proportionality when they review its framework through the review reports under Article 6(5) or Article 16(2). That means the file must show the inputs (headcount, turnover, balance sheet, service portfolio, dependence on ICT providers), the reasoning that links those inputs to the chosen controls, and the decisions to adopt or defer specific measures. Delegated Regulation (EU) 2024/1774 adds a practical test: entities must weigh increased or reduced complexity in areas such as encryption, ICT operations security, network security, and change management when designing their policies. Ask your team to record, for each of those areas, what the entity's complexity is, why the chosen control level matches it, and who in the management body approved that position.
Confirm three things early. First, whether your entity meets the definition of microenterprise in Article 3(60), which combines an employee threshold with turnover or balance sheet limits, because several articles exempt microenterprises or relax their requirements. Second, whether a simplified regime under Article 16 applies to you, since that regime is a separate route with its own qualifying conditions rather than a sliding scale. Third, whether the sectoral rules that apply to your entity type, which Directive (EU) 2022/2556 amended, change how the proportionality analysis should be framed. Where the answer is unclear, confirm the position with your national competent authority or your legal adviser before you document it, because a proportionality argument that rests on a wrong threshold is weak from the start. If an outside party helps you prepare the evidence, it can organize the records and test the controls, but the entity still owns the decision and the independent assessment is performed by others.
Which entities and chapters the proportionality principle changes
Article 4 does not lower the bar for everyone equally. Four scoping decisions determine how much of DORA's ICT risk work actually changes for a given entity, and each should be settled and documented before the framework is designed.
Confirm the entity type under Article 2(1)
Article 2(1) lists 20 types of financial entity, from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories, and also covers ICT third-party service providers under point (u). The entity type determines which chapters apply, which national competent authority supervises the entity, and which sectoral rules apply. Check the point that matches your licence or registration, and record it in the scoping memo, because later proportionality arguments depend on it.
Test the microenterprise definition
Article 3(60) defines a microenterprise as a financial entity, other than a trading venue, central counterparty, trade repository or central securities depository, that employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total of no more than EUR 2 million. Many articles exempt microenterprises or relax their requirements. Confirm headcount and both financial thresholds against the reporting period, and confirm with counsel how the turnover or balance sheet test applies if the entity sits inside a group.
Weigh the complexity elements in 2024/1774
Article 1 of Delegated Regulation (EU) 2024/1774 requires entities to weigh elements of increased or reduced complexity when designing ICT security policies. The listed areas include encryption and cryptography, ICT operations security, network security, ICT project and change management, and the potential impact of ICT risk on data and continuity. Document the reasoning for each element, because supervisors look at why a control was scaled down, not only at the outcome.
Map Chapter II as the scaled core
Article 4(1) requires financial entities to implement Chapter II, the ICT risk management articles from Article 5 to Article 16, in line with proportionality. The scaling applies to how each obligation is met, judged against size, overall risk profile, and the nature, scale and complexity of services and operations. Build the framework so every Chapter II article has a named owner, a proportionate approach and a written rationale, rather than an exemption that nobody recorded.
Check where other chapters apply proportionately
Under Article 4(2), Chapter III on incidents, Chapter IV on testing and Section I of Chapter V on ICT third-party risk apply proportionately only where their own rules say so. Entities often assume these chapters scale automatically, which is not the case. For each of these chapters, list the specific provisions that contain a proportionality or microenterprise carve-out, and treat everything else as full obligation.
How size, risk profile and complexity change ICT risk obligations
Article 4(1) makes proportionality the lens for Chapter II, the ICT risk management chapter, but it does not switch requirements off. The three inputs are an entity's size, its overall risk profile, and the nature, scale and complexity of its services, activities and operations. These interact: a small firm with a high-risk profile, such as one whose core process depends on a single outsourced cloud service, may need more depth in certain controls than a larger firm with a simple, well-isolated estate. The Delegated Regulation (EU) 2024/1774 gives the complexity side concrete content. When designing ICT security policies, entities must weigh increased or reduced complexity in encryption and cryptography, ICT operations security, network security, ICT project and change management, and the potential impact of ICT risk on data and continuity. Confirm with your supervisor how they expect those factors to be documented, because the weighting itself is the evidence.
Proportionality changes the depth of an obligation and the evidence expected for it. It does not decide whether a requirement exists. A firm of any size still needs an ICT risk management framework, still needs to identify its ICT assets and still needs to respond to and recover from incidents. What shrinks is the scale of the process: how often reviews happen, how granular the asset inventory is, how formal the testing is and how many people sit on the approval chain. (Illustrative example: a two-person investment firm might document a yearly review of its asset list in a short signed register, where a large bank would maintain a continuously updated configuration database with automated reconciliation.) Many articles go further and exempt microenterprises or relax requirements for them, so check article by article whether a relief applies before assuming it does.
Ask two questions before you rely on any relief. First, does your entity meet the microenterprise definition in Article 3(60), which combines headcount under 10 with turnover or balance sheet total of no more than EUR 2 million, and is it outside the excluded categories such as trading venues and central counterparties? Second, does the specific article you are relying on actually grant the relief, or does it only say the entity should apply the principle? Record both answers in your framework review. Supervisors check that proportionality was applied reasonably, and under Article 4(3) they look at how you applied it when they review the framework through the reports requested under Article 6(5) or Article 16(2).
How supervisors test whether proportionality was applied reasonably
This table sets out how a competent authority reviews proportionality under Article 4(3), what it asks the entity to produce, and where reviews usually stall. Read it as a checklist of the documents to have ready before a supervisory review of the ICT risk management framework.
| Review element | What the supervisor examines | Evidence the entity should hold | Common finding |
|---|---|---|---|
| Entry point | The review report on the ICT risk management framework requested under Article 6(5), or under Article 16(2) for simplified-regime entities | Latest annual review report showing how the framework was assessed and what changed | Review report restates the framework without explaining why its scope fits the entity |
| Proportionality rationale | Whether the entity weighed size, overall risk profile, and the nature, scale and complexity of its services | Written proportionality rationale dated and approved by the management body | Reasoning is absent, or it appears only after a request from the authority |
| Scoping memo | Which Chapter II measures were applied in full, adapted or not applied, and on what basis | Scoping memo mapping each measure to the entity's activities and risk profile | Measures are dropped without a recorded decision or risk acceptance |
| Complexity factors | Whether the elements in Article 1 of Delegated Regulation (EU) 2024/1774 were considered in the policies | Policy set showing encryption, operations, network, change and impact considerations | Policies are generic templates that do not reflect the entity's own complexity |
| Exemptions and simplifications | Any reduced requirement for microenterprises or the Article 16 regime, and whether eligibility was confirmed | Eligibility assessment against the Article 3(60) thresholds or the Article 16 criteria, with dates | Exemption is claimed with no eligibility test or with figures that are out of date |
| Policy set consistency | Whether policies, procedures and tools agree with the stated proportionality decisions | Cross-referenced policy register and evidence that controls operate as documented | Policies promise controls that operations teams cannot show |
| Management body oversight | Whether the management body approved the scope and reviewed its basis | Board minutes, approval records and training evidence | Approval is recorded as a formality with no evidence of challenge |
| Change over time | Whether the proportionality decision was revisited after growth, new services or significant incidents | Versioned rationale and change log linked to review cycles | Decision was made at launch and never updated despite material change |
Documenting a defensible proportionality decision
The sequence turns Article 4 from a general claim into a dated, approved record that shows which Chapter II requirements were scaled, why, and by whom. That record is what a competent authority reviews when it checks the ICT risk management framework.
Confirm the entity classification
Start by fixing the entity's regulatory category under Article 2(1) and whether it meets the Article 3(60) definition of a microenterprise, which turns on headcount and on turnover or balance sheet total against EUR 2 million. Record the entity type, the sectoral directive it falls under, and whether it is an essential or important entity under NIS2 if that applies. Ask legal or compliance to sign the classification memo. The step is done when every later decision cites this memo as its starting point, and the reader can see which exemptions or simplified regimes are in play.
Map each Chapter II requirement to a depth
Work through Articles 5 to 16 one article at a time and assign each requirement a planned depth, such as full, scaled or simplified, based on the entity's size, risk profile and the nature, scale and complexity of its services. Keep the mapping at the level of individual obligations, not chapter headings, so that a reviewer can follow the logic for, for example, backup or ICT business continuity separately from identification. The output is a table with one row per requirement, the chosen depth, and a short justification. Where a requirement cannot be scaled, mark it as fixed so the record shows the decision was made deliberately.
Record the complexity and risk factors
For the ICT security policies, weigh the increased or reduced complexity factors named in Delegated Regulation (EU) 2024/1774, including encryption and cryptography, ICT operations security, network security, ICT project and change management, and the potential impact of ICT risk on data and continuity. Write down the facts behind each rating, such as the number of ICT systems, the degree of outsourcing, and the criticality of the services supported. Evidence for each factor should point to an inventory, an architecture diagram or a risk assessment. The step closes when each factor has a rating and a source document that a third party could check.
Check the Chapter III, IV and V boundaries
Confirm which parts of Chapters III (incidents), IV (testing) and Section I of Chapter V apply proportionately and which apply in full, because Article 4(2) limits proportionality in those chapters to what their own rules provide. Record the specific provision relied on for every reduced obligation. This prevents an entity from scaling incident reporting or testing on the basis of general size arguments that the chapter text does not support. The output is a short boundary note that sits alongside the Chapter II table and is reviewed together with it.
Approve the rationale through the management body
Present the classification memo, the requirement table, the complexity ratings and the boundary note to the management body, which carries ultimate responsibility for ICT risk under Article 5. The minutes should show that members discussed the scaling choices, asked questions and approved the decision, with a named owner for each area. Any choice the board did not accept should be reworked and resubmitted. The step is complete when the approved decision carries a date, a version number and the names of the approving members.
Feed the decision into the framework review report
Carry the approved rationale into the ICT risk management framework and into the review report that Article 6(5) requires the entity to produce, so the proportionality choices are reviewed each cycle rather than left in a one-off file. Note what changed since the last review, such as new services, acquisitions or a change in headcount that could move the entity across a threshold. Competent authorities review this report under Article 4(3), so it should let a reader trace each scaled requirement back to its justification. The step closes when the review report references the approved decision and records any updates.
Evidence that shows the proportionality decision holds up
Article 4 does not ask for a single document, so an assessor will look for a set of records that agree with each other. The cards below cover the artifacts a supervisor is most likely to ask for when testing whether the scaling of Chapter II was reasonable, and the habits that keep each one current between annual reviews.
Written proportionality rationale
This is the entity's own explanation of how size, overall risk profile, and the nature, scale and complexity of its services shaped the ICT risk management framework. It should name which Chapter II measures were scaled and why, and which were applied in full. Because Article 4(3) points supervisors to how the entity applied proportionality, this document is the first thing they read. Check that it still matches the current business model, product list and risk appetite, and update it whenever any of those change materially.
Entity classification record
This record shows where the entity sits on the size and complexity scale, including whether it meets the microenterprise definition in Article 3(60), which turns on headcount and the EUR 2 million turnover or balance sheet thresholds. It also shows the entity type under Article 2(1) and any simplified regime it relies on. Record the date of each measurement and the source figures. Reassess it at each annual review, because a classification that was valid last year can change after a merger, a growth period or a shift in activity.
Complexity assessment against 2024/1774
This assessment works through the elements of increased or reduced complexity that Delegated Regulation (EU) 2024/1774 asks entities to weigh, including encryption, operations security, network security, project and change management, and the potential impact of ICT risk on data and continuity. Each element should carry a conclusion and the evidence behind it. Assessors often find that an assessment lists the elements without reasoning, so confirm that each conclusion explains why the chosen level of control is enough.
Approved ICT policy set
The policies that implement the framework should show the proportionality decision in practice. A small entity may hold shorter policies with clear owners, while a larger one needs more detailed procedures. Each policy should carry a version, an approval date and the name of the management body member or committee that approved it. Confirm that the policies reference the same scope and systems as the rationale. Mismatches between the policy set and the rationale are a common reason a supervisor questions the whole decision.
Annual framework review report
Article 6(5) requires a review report, which Article 4(3) links directly to proportionality. The report should state whether the scaling still fits the entity, record any changes in size, risk or activity, and set out the actions taken since the previous review. Keep dated versions so that the history of decisions can be traced. Ask the management body to approve the report, and keep the minutes that show the discussion, because an approved report without a record of challenge carries less weight.
Management body sign-off trail
Under Article 5, the management body remains responsible for ICT risk, so the evidence should show that its members approved the proportionality decision and the policies behind it. Keep the agenda papers, the minutes and the signed approvals. Between reviews, log any material change, such as a new service line or a major ICT provider, and show when the board was told. This trail answers the question an assessor most often asks: who decided that this level of control was enough, and when.
What documenting proportionality costs in effort and money
This table breaks down the work behind a proportionality rationale, marking which parts are one-time and which recur, who usually does them, and what pushes effort up or down. No figures are given because none are supplied for this topic, so use it to scope internal effort and to frame what to ask for in a quote.
| Cost component | Who usually does it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Classifying the entity by size, risk profile and complexity | Compliance lead with finance and risk input | One-time, then reviewed annually | Number of legal entities and business lines; a clear, documented profile shortens the work |
| Interpreting Article 4 and the Article 3(60) microenterprise test | Legal or regulatory counsel | One-time, revisited when law or RTS change | Whether the entity sits near thresholds or relies on exemptions in several articles |
| Justifying depth for each Chapter II area | CISO, IT risk function and control owners | Initial build, then yearly update | Number of ICT services and systems in scope; reuse of an existing risk framework lowers effort |
| Management body review and approval | Management body with ICT risk function support | Recurring, at least yearly and after material change | Quality of the pack; short decision papers with clear options reduce meeting time |
| Documenting how complexity factors were weighed under the 2024/1774 RTS | Security architecture and operations teams | One-time per major change, then maintained | Degree of change in encryption, network or project management practices |
| External review of the rationale | Independent assessor or advisor (optional, scope agreed in writing) | Usually one-time, repeated when scope changes | Group structure, number of entities and whether the review covers all Chapter II areas or only the rationale |
| Group and intra-group alignment | Group compliance and each subsidiary's board | Recurring as group structure changes | Number of subsidiaries, shared services and whether group policies are adopted locally |
| Supervisory evidence retention | Compliance and records owners | Recurring | Retention method; a single evidence register with dated versions reduces rework during supervisory requests |
Who owns the proportionality decision and who can prepare the evidence
Your organization owns the proportionality decision. Article 4(1) requires the financial entity to implement Chapter II in line with proportionality, taking into account its size, overall risk profile, and the nature, scale and complexity of its services, activities and operations. The management body carries ultimate responsibility for ICT risk under Article 5, so it must approve the reasoning, not only receive a summary of it. Internal staff also hold the operational facts that drive the decision, such as which services are critical and how the business actually runs.
- Scope ownership: Decide which Chapter II measures apply at which depth and record why each choice fits your profile.
- Management body sign-off: Board or management body approval of the classification and the rationale, with minutes that show real discussion.
- Business input: Business owners confirm service criticality, dependencies and the consequences of disruption.
- Ongoing review: Revisit the decision when size, services or risk profile change, and during the annual framework review.
- Accountable contact: Name an owner who can explain the reasoning to a competent authority during supervision.
Before sign-off, confirm that the decision references the specific Article 4 factors and the relevant RTS provisions, not a generic statement of intent.
An implementation partner can prepare the analysis and evidence that your team reviews and approves. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for assessments. It does not decide your proportionality level, and it does not issue audit reports, attestations or certifications. The partner's work product is an input to your governance, not a substitute for it.
- Classification analysis: Draft a structured analysis of size, risk profile and complexity against each Chapter II area, for your review.
- Evidence set: Assemble configuration exports, logs, inventories and test outputs that show what is actually in place.
- Documentation drafts: Prepare policy and procedure drafts that your owners edit and approve.
- Gap visibility: Identify where stated proportionality choices are not yet supported by operating controls.
- Scope agreement: Define deliverables, inputs and responsibilities in writing before work starts.
Before engaging a partner, confirm in writing who signs each document, who holds the evidence after handover, and that no output is presented as an assessment or certification.
Competent authorities review how proportionality was applied. Under Article 4(3), they consider the approach when they review your ICT risk management framework, using the review reports requested under Article 6(5) or Article 16(2). Supervision for most entities sits with the national competent authority listed in Article 46, and the ECB covers significant credit institutions. Their questions focus on whether the reasoning is documented, specific and consistent with what your systems actually do.
- Reasonableness test: Authorities ask whether the chosen depth matches your size, risk profile and complexity.
- Documented rationale: A decision with no written reasoning is hard to defend, however sound the controls are.
- Operating evidence: Supervisors look for proof that measures run in practice, not only in policy.
- Independent assurance: Where an external auditor is engaged, they test the controls and report their own findings.
- Limits of outside work: Neither an authority nor an auditor relies on a vendor's readiness output as its conclusion.
Before supervision, confirm which authority supervises your entity and what review report, if any, it expects under Article 6(5) or Article 16(2).
Where proportionality arguments usually fail review
Supervisors do not reject proportionality because an entity scaled its controls down. They reject it when the reasoning is missing, thin or out of date. The cards below cover the gaps that recur in Article 4 reviews, each paired with a practical fix an entity can check before its framework is examined.
Reasoning that was never written down
An entity may have decided, informally, that a control is disproportionate, but nothing records the size, risk profile or service complexity behind that choice. Article 4(3) directs competent authorities to look at how proportionality was applied in the framework review. If the reasoning is absent, the reviewer cannot tell a considered decision from an omission. Fix: record each scaled-down requirement with the factor relied on, the decision owner and the date, and keep it with the ICT risk management framework documents.
Relying on microenterprise status unchecked
Microenterprise status depends on a headcount limit and on turnover or balance sheet thresholds, and several articles relax duties only for entities that meet them. An entity that assumes it qualifies, without testing both conditions against current figures, risks applying an exemption it does not hold. Check the employee count, the annual turnover and the balance sheet total against the definition in Article 3(60) at each review date, and confirm that the entity type is not excluded.
Exemptions applied to the wrong chapter
Article 4(2) means proportionality operates differently across DORA. Chapter II is scaled under the principle itself, while Chapters III and IV and Section I of Chapter V apply proportionately only where their own rules say so. An entity that relaxes incident reporting or testing because it is small, when no specific provision allows it, has misread the Regulation. Fix: map each reduced requirement to the article that permits the reduction, and flag any reduction without a named basis.
Rationale not refreshed after growth
A proportionality decision made at launch can become wrong after the entity hires, enters new markets, adds critical functions or outsources a core service. Each change can move the entity into a different size band or complexity profile. Reviewers look for evidence that the rationale was revisited, not only that it existed once. Fix: tie the proportionality record to the annual framework review and to triggers such as new services, acquisitions, headcount changes and new third-party arrangements.
Complexity factors left unweighed
Delegated Regulation (EU) 2024/1774 asks entities to weigh elements of increased or reduced complexity when designing their ICT security policies, including encryption, operations security, network security, change management and the impact of ICT risk on data and continuity. A rationale that addresses size alone and ignores these factors is incomplete. Check that each factor appears in the record, with a finding for each, even where the finding is that no reduction applies.
Proportionality without a risk tie
A common failure is to describe the entity as small and stop there, without linking the scaled measure to the risk it leaves open. Supervisors examine whether the residual risk is accepted by the management body and whether the reduced control still addresses the threat it was meant to address. Fix: for every reduced control, state the residual risk, the compensating measure if any, and the management body approval that accepts it.
Common questions about DORA Article 4 proportionality
Can a small financial entity skip Chapter II of DORA?
No. Article 4(1) requires every financial entity to implement Chapter II, the ICT risk management requirements, in line with proportionality, so the duty applies to everyone in scope. What scales is the depth and form of the work. Size, overall risk profile, and the nature, scale and complexity of services, activities and operations shape how much is needed. Separately, DORA defines a microenterprise by headcount and turnover or balance sheet thresholds (Article 3(60)), and many articles exempt microenterprises or relax requirements for them. Small investment firms and some payment, e-money and pension entities may also qualify for the simplified regime in Article 16. Confirm your category with your national competent authority before relying on any exemption, because the exemption is article-specific and a microenterprise classification does not remove the Chapter II duty.
How much effort does a proportionality rationale take to write?
The effort depends on how many systems, services and third parties your entity runs and how much of that work already exists in documents. A rationale that explains why your ICT security policies are sized the way they are needs an inventory of services, a written view of your risk profile, and a record of the decisions you made about complexity. Where those inputs exist, the writing is a review task. Where they do not, the first build is larger because the inventory and risk view come first. Cost drivers include the number of business functions in scope, the degree of cloud and third-party dependence, and whether the rationale must be reconciled with other frameworks. Ask any provider for a written scope listing the artifacts to be produced and the review cycle, since the rationale must be revisited as the entity changes.
Can internal staff write the proportionality rationale themselves?
Yes, internal staff can write it, and the management body remains responsible for approving it. Article 5 places ultimate responsibility for ICT risk on the management body, so the people who draft the rationale need enough understanding of the business, the ICT estate and the risk framework to defend each decision. Teams that already run risk assessments, asset inventories and security policies usually have most of the raw material. Common gaps are an incomplete inventory of ICT-supported functions, weak documentation of why a control was scaled down, and no evidence that the decision was reviewed. An outside implementation partner can help structure the work and check its consistency, but it cannot make the entity's risk decisions or sign off on its behalf. Independent assessment is a separate matter, handled by the competent authority or an auditor the entity engages.
What will a supervisor ask for when checking proportionality?
Under Article 4(3), competent authorities consider how the entity applied proportionality when they review its ICT risk management framework. They do this through the review reports described in Article 6(5) or Article 16(2), so the review report is the central document. Expect requests for the scoping decisions behind each simplified or scaled measure, the inventory and risk assessment that justify them, evidence that the management body approved and reviewed the framework, and proof that the decisions were revisited when the business changed. Supervisors also test whether the reasoning is consistent across policies, for example whether a lighter control in one area matches the risk recorded elsewhere. Gather these records in one place before a review starts, and confirm the expected format with your competent authority.
How does Article 4 interact with NIS2 for financial entities?
Article 1(2) of DORA makes it a sector-specific Union legal act for the purposes of Article 4 of the NIS2 Directive for financial entities identified as essential or important entities under NIS2. In practice, this means DORA's sector-specific rules take precedence for the financial entities it covers, and entities should map which NIS2 obligations DORA already addresses and which remain. Proportionality logic runs in both frameworks, so a single well-documented rationale can serve both if it names each framework's requirements. Confirm with your national authority how NIS2 transposition applies to your entity, because member state implementation affects supervision and reporting channels. Do not assume a mapping is complete without checking the text of both instruments.
Does the Digital Omnibus proposal change Article 4 proportionality?
The Commission's Digital Omnibus proposal COM(2025) 837 of 19 November 2025 would amend DORA Article 19 so that major incident reports and voluntary threat notifications go through a single entry point under NIS2. It does not, as supplied, change the proportionality principle in Article 4. As of October 2026, the European Parliament's Legislative Observatory lists procedure 2025/0360(COD) as awaiting committee decision, so the outcome is uncertain. Plan around the current text of Regulation (EU) 2022/2554, and track the procedure for changes to reporting channels that could affect your incident process. Your legal or compliance team should review the proposal and its status before making structural changes.
Can open-source platforms help document proportionality decisions?
Open-source governance and risk tools can hold the inventory, risk register, control mappings and review records that a proportionality rationale depends on. CISO Assistant, released under AGPL-3.0-only, ships more than 200 frameworks, including DORA, and supports audits and compliance assessments against them. This can keep scoping decisions linked to the controls they affect. Confirm the current feature set against the project's documentation before you depend on it, and remember that a tool records decisions but does not make them. DeployOpen can plan, implement and integrate self-hosted tooling like this inside your own infrastructure, and prepare the evidence a supervisor will request, while the entity owns the decisions and the independent assessor provides any formal assessment.
How DeployOpen prepares proportionality evidence
DeployOpen prepares the proportionality evidence that an organization then reviews, owns and approves. Work starts with a written scope that names the entity type, the ICT services and systems in the Chapter II perimeter, the business functions they support and the people who will sign off each decision. Because most engagements are fixed-scope, the scope, deliverables and timelines are agreed in writing before any analysis begins, and a quote follows directly from that written scope. Ask for the scope document to list the size and turnover data you will rely on, the assumptions behind the complexity assessment and the named owners on the client side.
Within that scope, DeployOpen prepares the classification analysis for Article 4: a record of the entity's size, overall risk profile and the nature, scale and complexity of its services, followed by the elements of increased or reduced complexity that Delegated Regulation (EU) 2024/1774 asks you to weigh, such as encryption, ICT operations security, network security, change management and the impact of ICT risk on data and continuity. Alongside it, the team prepares the control evidence and draft documentation that show how each applied measure was chosen, including where a simplification was taken and why. Every item is a draft for your management body and control functions to approve. You should confirm in advance which of these records your competent authority has asked for during its review under Article 4(3).
DeployOpen does not issue assessments, attestations or certifications, and it does not decide whether your proportionality choices are acceptable. That judgment belongs to your management body and, in the end, to your competent authority, which may test the reasoning against your review reports. The practical test for any provider is whether it will put scope exclusions, assumptions and open risks in writing and leave the sign-off decisions with you. Before you engage anyone, ask which decisions remain yours, how changes to the scope after signature are priced and handled, and who in your organization will own the evidence once the engagement closes.
