Article 6 DORA ICT risk management framework requirements

What DORA Article 6 requires from an ICT risk management framework

Article 6 requires a financial entity to hold a sound, comprehensive and well-documented ICT risk management framework, sitting inside its overall risk management system. The framework must set out the strategies, policies, procedures, ICT protocols and tools needed to protect all information assets, ICT assets and relevant physical infrastructure. If your competent authority asks for it, you must be able to show that this framework exists in writing, that it is owned at management level, and that it is kept current. Start by checking whether you already have one document set that covers all of these elements, or whether the pieces sit in separate policies that nobody has mapped back to DORA.

The article names several parts that work together. Strategies set direction, policies state the rules, procedures describe the steps, and protocols and tools are the concrete mechanisms that enforce them. Entities other than microenterprises must also assign ICT risk management and oversight to a control function with appropriate independence, and keep risk management, control and internal audit functions separate under the three lines of defence model or an internal risk management and control model. The framework must be reviewed at least once a year, and after major ICT-related incidents or supervisory instructions. Non-microenterprises must have it audited regularly by people with sufficient ICT risk expertise and independence. The digital operational resilience strategy ties these together by setting the ICT risk tolerance, analysing impact tolerance for disruptions, and defining information security objectives with key performance indicators and key risk metrics.

The framework is hard to evidence because it is a set of living documents, not a single control that either works or does not. An assessor will look for consistency: whether the risk tolerance in the strategy matches the thresholds in the procedures, whether the annual review actually changed something, and whether audit findings were tracked to closure. Version history, named owners, approval records and a dated review report usually carry more weight than the length of the documents. Confirm with your competent authority which review report format it expects, because Delegated Regulation (EU) 2024/1774 sets the content for that report and you should check the current text at EUR-Lex before drafting.

Which entities and systems the DORA Article 6 framework covers

Article 6 applies to almost every type of financial entity, but the depth of the obligation depends on the entity's category, its size and whether it qualifies for the simplified regime. The cards below cover the decisions that determine how much of the framework you must build, and what it must reach.

The 20 financial entity types

Article 2(1) lists 20 categories of financial entity, from credit and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Each category is in scope, so the first question is which point of Article 2(1) describes your legal entity, not which business line you run. Check the entity type against the list and record the answer in the framework's scope statement. Where a group contains several regulated entities, each one needs its own determination.

Microenterprise relief

Microenterprises are not exempt from Article 6, but several duties are lighter. The framework must still be documented and reviewed, though the review may run periodically rather than yearly. Microenterprises do not need an independent ICT risk control function or a separate internal audit duty under Article 6(4) and 6(6). Confirm your microenterprise status against the definition in the Regulation before you rely on these reductions, and document why you qualify.

Simplified regime under Article 16

Article 16 gives a lighter ICT risk management regime to qualifying small and non-interconnected investment firms, exempted payment and e-money institutions and small pension funds. Qualification depends on specific conditions, so verify each condition with your competent authority before you scale down. Even under the simplified regime, you must still keep a documented framework covering the core protective and recovery duties. Ask your advisers which Title III requirements in the technical standards still apply to you.

Scope of ICT, information and physical assets

Article 6(1) and 6(2) require the framework to protect all information assets, ICT assets and relevant physical infrastructure. In practice, this means the asset inventory must reach beyond servers and applications to data stores, endpoints, network devices, and the data centers, server rooms and office spaces that host them. Decide which physical sites count as relevant, and document the reasoning. An asset left out of the inventory is an asset the framework does not protect.

Group and intra-group ICT services

Where a group provides ICT services to its regulated entities, the framework must still cover how those services are controlled and monitored. Article 6(10) allows verification of compliance to be outsourced to intra-group or external undertakings, but the regulated entity stays fully responsible. Record each intra-group arrangement, the entity that operates the service, and the evidence the regulated entity receives. Confirm how the group's controls map to your own policies.

Third-party platforms in the framework

Third-party platforms, including self-hosted open-source software deployed in your own cloud accounts or data centers, belong in the framework when they support a business function or hold regulated data. Treat the platform as an ICT asset with its own owner, configuration baseline, patching schedule and backup. Where an external provider operates the platform, its arrangements also feed the ICT third-party risk process. Confirm with your provider which party holds each control so the framework does not assume coverage that no one owns.

How an assessor tests the DORA Article 6 framework

This table takes each element of Article 6 and sets out how a supervisor or internal reviewer would test it, the evidence to prepare, and the findings that appear most often. Read each row as a checklist for your own framework before any supervisory review. Competent authorities supervise through their own powers, and no certificate is issued for this framework.

Article 6 element	How it is tested	Evidence requested	Common findings
Documented ICT risk management framework	Reviewer checks that strategies, policies, procedures, protocols and tools exist in writing and cover information assets, ICT assets and relevant physical infrastructure.	Approved framework document, policy set with version history, mapping from each policy to the assets it protects.	Policies exist but do not cover physical infrastructure, or documents conflict with how systems actually run.
Independent control function	Reviewer confirms a named function owns ICT risk oversight and is separate from the teams that operate ICT systems and from internal audit.	Organisation chart, mandate or charter for the control function, reporting lines to the management body, evidence of segregation.	Operations staff also approve their own risk acceptances, or the control function lacks authority to challenge system owners.
Annual review of the framework	Reviewer checks that the framework was reviewed within the last year and that the review addressed changes in threats, systems and incidents.	Dated review records, change history of framework documents, minutes showing management body consideration.	Review happens on paper only, with no changes recorded despite new systems or incidents.
Event-driven review	Reviewer looks for a review after each major ICT-related incident, supervisory instruction or significant test or audit finding.	Incident-linked review tickets, post-incident update records, log of supervisory or audit actions and their closure.	No documented trigger process, so reviews after major incidents are missing or undated.
Review report on request	Reviewer asks for the report on the framework review and checks its content against the format set by the delegated regulation.	Review report ready to submit, with findings, changes made and approval by the management body.	Report is missing required content, or nobody can produce it quickly when the competent authority asks.
Internal audit of the framework	Reviewer checks that auditors with ICT risk skills and independence tested the framework on a regular basis, not only the operations they audit.	Audit plan covering the framework, audit reports, auditor qualifications, scope statements showing coverage of ICT risk.	Audit plan omits the framework itself, or auditors lack ICT expertise and rely on checklists from earlier cycles.
Follow-up on critical audit findings	Reviewer samples critical findings and traces them from the audit report to verified remediation.	Findings register with owners, due dates, evidence of fix and independent verification, escalation records for overdue items.	Critical findings are closed by the owner without verification, or overdue items are carried forward without escalation.
Resilience strategy with risk tolerance and metrics	Reviewer checks that the strategy states ICT risk tolerance, impact tolerance for disruptions, information security objectives, key performance indicators and key risk metrics, and that these are reported.	Approved strategy, risk tolerance statement, KPI and risk metric dashboards, management body reports showing tolerance breaches.	Tolerance is stated in general terms with no measurable thresholds, or metrics are collected but never reviewed by management.

How to build the DORA Article 6 framework step by step

This sequence turns Article 6 into a documented, governed and audited framework, with each step producing a named output that the management body and competent authority can review.

Confirm entity type and proportionality
Start by establishing which type of financial entity you are and whether the proportionality principle of Article 4 changes what you must build. Confirm with your legal and regulatory team whether you are a microenterprise, a simplified-regime entity under Article 16, or a full-scope entity, because this decides whether the independent control function and internal audit requirements apply in full. The output is a short scoping memo signed by the management body that records the entity category, the applicable obligations and the reasoning. You know the step is done when every later step can point back to that memo.
Set the resilience strategy, risk tolerance and metrics
Draft the digital operational resilience strategy required by Article 6(8). It should set the risk tolerance level for ICT risk, analyse impact tolerance for ICT disruptions, define information security objectives, and choose key performance indicators and key risk metrics that management can track. It should also explain the ICT reference architecture. The management body approves the strategy, and the output is an approved strategy document with a metrics register listing each KPI owner and data source. The step closes when each objective can be traced to a measurable indicator.
Write the policy and procedure set
Build the documented framework itself: strategies, policies, procedures, ICT protocols and tools that protect information assets, ICT assets and relevant physical infrastructure, as Article 6(1) and (2) require. Write each document against the strategy from the previous step, and map it to the ICT risk management technical standards in Delegated Regulation (EU) 2024/1774 so that gaps are visible. Assign each document an owner, an approver and a review date. The output is a versioned document set and a traceability matrix that links each policy to its strategy objective and to the tools that enforce it.
Assign the control function and its reporting line
Designate the function responsible for managing and overseeing ICT risk, as Article 6(4) requires for entities other than microenterprises. Make sure its independence is real: it should sit apart from the teams that operate ICT systems, and it should have a direct line to the management body. Define how ICT risk management, control and internal audit are segregated under the three lines of defence model or an internal risk management and control model. The output is an approved organisation chart, a role description for the control function, and a reporting line document that the management body has signed.
Schedule the annual review and event-driven triggers
Set a calendar for the annual review of the framework required by Article 6(5), and list the event triggers that force an earlier review: major ICT-related incidents, supervisory instructions, and conclusions from testing or audits. Plan who prepares the review, who challenges it and who approves it. Prepare the review report in the format set by Article 27 of Delegated Regulation (EU) 2024/1774, and confirm the format and content with your competent authority if it has issued guidance. The output is a review procedure, an approved review calendar and a report template that can be produced on request.
Plan internal audit of the framework
For entities other than microenterprises, schedule regular internal audits of the ICT risk management framework under Article 6(6). Select auditors who have sufficient ICT risk expertise and who are independent of the control function they review. Agree the audit universe, sampling approach and reporting route to the management body. Ask your audit committee or board to confirm how audit scope is set and whether external specialists will support the work. The output is an approved internal audit plan and terms of reference that show coverage of every framework component at least once in the planned cycle.
Set up the follow-up process for audit findings
Establish the formal follow-up process required by Article 6(7), which applies to all entities. Log every finding, classify critical ICT audit findings, assign an owner and a remediation date, and define how each closure is verified before the finding is marked complete. Escalate overdue critical items to the management body. The output is a findings register, a verification procedure and a reporting pack for the management body. You know the step is done when a sample of closed findings can be traced to independent verification evidence.

Evidence that satisfies the DORA Article 6 framework

Article 6 is tested by documents and the trail behind them. An assessor will look for an approved framework, a resilience strategy with measurable tolerances, an independent control function, an annual review, audit coverage and proof that findings were closed. Each card below is a distinct artifact, and each needs a named owner and a routine that keeps it current between competent authority reviews.

Approved framework document set

The strategies, policies, procedures, ICT protocols and tools that make up the framework, approved by the management body and kept under version control. Check that every policy names an owner, an approval date and the version in force, and that superseded versions remain retrievable. Review the set at least once a year and after every major ICT-related incident, recording each change and the reason for it. XWiki-style page history or a git-backed repository can show who changed what and when, which is the trail an assessor asks for first.

Digital operational resilience strategy

The strategy sets the risk tolerance for ICT risk, the impact tolerance for ICT disruptions, information security objectives, key performance indicators and key risk metrics, and it explains the ICT reference architecture. Confirm that each tolerance is stated in a measurable form and that the metrics are tied to a named data source. Refresh the KPI values on a fixed cadence so the strategy reflects current performance, not the figures at approval. Record management body decisions on any tolerance breach.

Control function mandate and reporting lines

Evidence that a control function with appropriate independence owns ICT risk management and oversight, and that it is segregated from operational and internal audit roles. The mandate should define its authority, access to the management body and escalation paths. Keep a current organization chart, role descriptions and minutes of periodic reporting. Revisit the mandate when reporting lines change, because a reorganization that places the function under a system owner weakens the independence argument.

Annual framework review report

The written review of the ICT risk management framework, covering changes in risk, incidents, test results and supervisory instructions, with the format and content set by Article 27 of Delegated Regulation (EU) 2024/1774. Check that each recommendation has an owner, a decision and a status. Prepare the report as a running file rather than a single annual document, so that findings from incidents and tests are logged during the year and the report can be produced on request.

Internal audit plans and reports

Entities other than microenterprises must have the framework audited regularly by auditors with sufficient ICT risk expertise and independence. Keep a risk-based annual audit plan, scope statements, working papers and issued reports, plus evidence that the auditors were independent of the teams they reviewed. Where ICT specialists are contracted, document their competence and conflicts checks. Confirm that the plan covers the whole framework over time, not only the areas that were audited last year.

Finding tracker with remediation evidence

A single register of critical ICT audit findings, with the owner, deadline, root cause, the remediation performed and the verification that closed it. Article 6(7) requires a formal follow-up process for timely verification and remediation, so the register should show who checked each fix and when. Reopen items when verification fails. Link each closed item to the change record or test result that proves the fix, because an assessor will sample entries and ask for that proof.

What meeting the DORA Article 6 framework costs

This table breaks down the cost components of documenting, governing, reviewing and auditing the Article 6 ICT risk management framework, showing who is paid, whether each cost is one-time or recurring, and what moves it. Use it to frame a request for a fixed-scope quote, since DORA sets no fixed price and the figure depends on your written scope.

Cost component	Who is paid or who bears effort	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendors for governance, GRC or documentation platforms	Recurring (subscription or support); one-time setup	Number of users and entities; self-hosted open source can remove license spend but adds hosting and support effort
Internal engineering and compliance time	Your ICT, security and compliance staff drafting strategies, policies and procedures	One-time build, then recurring upkeep	Number of ICT services, number of policies and how many already exist and map to Article 6
Evidence upkeep and annual review	Control owners and the ICT risk control function producing evidence and the review report	Recurring, at least yearly and after major incidents	Frequency of changes to systems, number of incidents and supervisory instructions, quality of version history
Implementation partner readiness support	An implementation partner preparing systems, documentation and evidence under a written scope	One-time, sometimes followed by retainer support	Entity size, gap between current documents and Article 6 requirements, and the number of systems in scope
Internal audit effort	Your internal audit function, which must be sufficiently independent and skilled in ICT risk	Recurring, on a regular basis	Audit universe size, number of audit findings and the effort to verify remediation under the follow-up process
External review and assessment	Independent auditors or assessors, where engaged by you; competent authorities may request the review report	Recurring or on request	Scope of review requested, number of open critical findings and whether the review report is requested by the competent authority
Remediation of audit findings	Owners of affected systems and processes, plus any vendors they depend on	Recurring as findings arise	Number and severity of findings, and whether controls were documented before they were tested

Open-source tools that hold DORA Article 6 evidence

Article 6 asks for a documented framework, an annual review and a record of who decided what. The three tools below can hold different parts of that record: assessment mapping, version history of the framework documents, and role-based access to the documents themselves. Each one covers a different slice, and none of them replaces the controls or the signed-off content.

CISO Assistant for DORA assessments

CISO Assistant (AGPL-3.0-only) ships DORA among more than 200 frameworks and runs audits and compliance assessments against them, with automatic mapping between frameworks. For Article 6, it can hold the register of ICT risk controls, the assessment results and the findings that feed the annual review. Before relying on it, confirm that its DORA content matches the articles and delegated regulations that apply to your entity type and scope, and record who reviewed that content. The AGPL-3.0-only license requires you to check obligations if you modify and distribute the software or offer it as a network service.

XWiki version history for framework documents

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For Article 6, this gives you a verifiable trail for the ICT risk management framework, its policies and the strategy document, so you can show an assessor what the framework said at the time of each annual review or after a major incident. Check that your retention and export practices meet your own record-keeping rules, since version history alone does not prove approval.

BookStack role-based access to policies

BookStack (MIT) assigns abilities through the roles given to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. For Article 6, this lets you restrict who can edit the framework and its policies while keeping them readable by the control function, internal audit and the management body. Confirm that the permission model matches your segregation of duties between the first, second and third lines, and document the role assignments as part of the evidence, since the tool shows access settings but not who approved them.

Who owns the DORA Article 6 framework, who prepares it and who reviews it

The financial entity owns its ICT risk management framework, and no outside party can take that ownership over. Article 6(4) expects a control function with appropriate independence to manage and oversee ICT risk, and the management body approves the strategies and policies that make up the framework. Because the people who run the systems hold the knowledge the framework must describe accurately, they supply most of the content.

Management body approval: Members approve the framework, the digital operational resilience strategy and the ICT risk tolerance level, and the minutes must show that approval.
Control function: A named ICT risk control function owns the framework document, the annual review cycle and the register of exceptions, and reports to the management body.
System owners: Platform and application owners confirm asset lists, configurations and recovery figures that the policies cite.
Document control: Someone keeps version history so each annual review shows what changed and who approved it. Tools such as XWiki keep page version history and BookStack sets permissions per role, subject to confirmation of the setup in your own environment.
Outsourced verification: Under Article 6(10), an entity may outsource verification of compliance to intra-group or external undertakings, but it remains fully responsible.

Check that the control function reports to a line separate from the teams whose work it reviews, and that every named owner appears in the approval record.

Common gaps in DORA Article 6 frameworks and how to close them

Most Article 6 gaps are not missing documents. They are documents without operating records, governance that does not separate the people who run ICT from the people who check it, and findings that never close. The cards below cover the gaps assessors most often raise and the evidence that closes each one.

Policies with no operating records

A framework that exists only as approved policies shows intent but not operation. Article 6 expects the strategies, policies, procedures, protocols and tools to be in use, so an assessor will ask for proof they ran: access reviews completed, patch cycles logged, backup restores tested. Check that every policy names the record it produces and where that record lives. Ask an implementation partner to map each policy to its evidence before the review. Evidence that closes it: dated run logs, completed review sign-offs and ticket trails linked to each policy.

Control function reports to those it oversees

Article 6(4) requires a control function with appropriate independence, segregated from ICT operations and internal audit under the three lines of defence or an equivalent model. A risk function that reports to the CIO who runs the systems it checks fails that test in practice. Check the reporting line, the function's authority to challenge decisions, and whether it can escalate directly to the management body. Evidence that closes it: an approved organisation chart, a terms of reference for the function and minutes showing challenges escalated.

No risk tolerance or metrics

The digital operational resilience strategy under Article 6(8) must set a risk tolerance level for ICT risk, analyse impact tolerance for ICT disruptions and define information security objectives with key performance indicators and key risk metrics. Many frameworks state principles but no thresholds, so nobody can tell when the entity is outside appetite. Set tolerance values the management body approves, pick metrics that have a data source, and define what happens when a threshold is breached. Evidence that closes it: an approved strategy with numeric thresholds, a metrics register with owners and a dashboard history.

No review after incidents or test findings

Article 6(5) requires the framework to be reviewed at least once a year and also after major ICT-related incidents, after supervisory instructions, and after conclusions from testing or audits. Teams often run the annual review and forget the event-driven triggers. Write the triggers into the review procedure, assign an owner for each, and record the decision even when no change is made. The report format and content are set by Article 27 of Delegated Regulation (EU) 2024/1774. Evidence that closes it: a trigger register, dated review records after each qualifying event and the review report in the required format.

Internal audit without ICT expertise

Article 6(6) asks for internal audit of the framework by auditors with sufficient ICT risk expertise and independence. Generalist audit teams often review the framework against process checklists and miss technical weaknesses such as segmentation gaps or unmanaged keys. Confirm that at least some auditors hold relevant ICT skills, or bring in qualified external reviewers under a defined scope, and confirm they report independently of the teams they test. Evidence that closes it: an audit plan covering ICT areas, auditor competency records and independent audit reports addressed to the management body.

Audit findings with no formal follow-up

Article 6(7) requires a formal follow-up process so that critical ICT audit findings are verified and remediated on time, and this applies to every entity. Findings often sit in spreadsheets with no owner, no due date and no verification step, so they are marked closed without evidence. Keep one findings register, assign each critical item to a named owner, require objective closure evidence and have someone independent of the owner verify it. Evidence that closes it: a findings register with owners and dates, closure evidence attached to each item and verification sign-offs.

Questions buyers ask about DORA Article 6 cost, effort and outsourcing

How much effort does a DORA Article 6 framework take and what does it need from the team?

The effort depends mainly on how many ICT systems, third-party services and business functions the entity supports, how much of that is already documented, and how many people must review and approve the framework. Most of the work is documentation and decision-making rather than technology: the strategies, policies, procedures and protocols Article 6(2) expects must be written, approved by the management body and tied to the systems they govern. The team needs a named owner for the framework, people who know the ICT estate in detail, and a business owner for each important function. Ask any provider to show the list of deliverables and the people each one needs from your side before you agree on a scope.

Can a small financial entity build its DORA ICT risk framework in-house?

Often yes, if the entity has someone with enough ICT risk knowledge to write the documents and keep them current. Article 6 applies a proportionate approach: microenterprises have lighter review cycles, and the simplified regime in Article 16 covers some small firms, so the entity should first confirm which regime applies to it. The harder parts are usually the independent control function and the internal audit requirement, which the entity must staff or buy in, and the risk tolerance and metrics that management must set and defend. An in-house team can prepare the framework, but the entity should check whether its people have the time and independence to run it alongside day-to-day operations.

What should a quote for DORA Article 6 readiness work include?

A useful quote states the scope in writing before any work starts. It should list the framework documents to be produced or updated, the systems and third parties in scope, the review and approval steps, and what the entity must supply, such as inventories, existing policies and interview time. Ask the provider to separate one-time work, such as the first framework and gap analysis, from recurring work, such as the annual review, evidence collection and support. Confirm who owns the outputs, whether the provider will train your staff to maintain them, and what happens if the scope changes. Ask explicitly which items the provider does not do, including any role in the independent review or assessment.

How long does a DORA Article 6 readiness project usually take?

The duration is driven by the size and condition of the existing documentation, the number of ICT systems and third-party arrangements in scope, how quickly management can review and approve the strategy, and how much evidence already exists. An entity with current policies and a maintained asset inventory will move faster than one starting from informal practice. Approval cycles by the management body and the availability of your staff for interviews often set the pace more than the writing does. Ask any provider to tie its timeline to named milestones and to list the approvals and inputs each milestone depends on, so you can see which delays are yours and which are theirs.

Can an outside firm write the DORA framework or certify that it complies?

An outside firm can help write and prepare the framework, but it cannot certify compliance. The organization owns its framework and must approve it through its management body. An implementation partner prepares documents, systems and evidence. DORA sets no certification scheme, and only the competent authority supervising the entity, or an independent auditor where the entity uses one, assesses compliance and issues reports. Confirm in writing that any provider understands these roles and will not present its deliverables as an audit result or attestation.

What must the annual review report on the ICT risk framework contain?

The annual review report summarizes how the entity reviewed its ICT risk management framework, what it found and what it changed. Article 6(5) requires the framework to be reviewed at least once a year and after major ICT-related incidents or supervisory instructions, with a report available to the competent authority on request. The format and content are set out in Article 27 of Delegated Regulation (EU) 2024/1774, so read that text directly before drafting. In practice the report should cover the scope of the review, the findings, the decisions taken, the owners of each action and the status of open items. Ask your provider to show how the report links to the audit findings and risk register.

How do you keep DORA framework evidence current between audits?

Evidence stays current when each control has a named owner, a review date and a defined source, and when changes to systems, suppliers or incidents trigger an update to the relevant document. Version history matters here: a wiki or document system that records what changed, when and by whom makes it easier to show an assessor how the framework evolved. Tools such as CISO Assistant support audits and assessments against DORA with mapping between frameworks, but they do not replace the entity's own judgment. Confirm how your chosen platform keeps history, how access is controlled and who approves changes before you rely on it for evidence.

How DeployOpen prepares DORA Article 6 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the ICT risk management framework Article 6 requires is backed by working systems and records. Your organization owns the framework and its sign-off, while DeployOpen prepares the systems, documentation and evidence that a competent authority or internal audit can review.

How we scope

Agree in writing which entities, business functions and ICT systems the Article 6 framework will cover.
Confirm which policies, procedures and protocols your organization already has and which must be written.
Define the review cycle, internal audit input and follow-up process your board expects, before work starts.

How we build

Set up the documented framework in self-hosted wiki and document tools so each policy has an owner and version history.
Configure access permissions so policy approvals, reviews and changes follow your management body's delegated roles.
Map the framework's strategies, risk tolerance and metrics to the controls and records your own systems produce.

How we hand over

Deliver the framework documents, control mapping and review record templates in formats your team can maintain.
Provide an evidence index showing where each Article 6 record is stored, who maintains it and how often it is updated.
Walk your control function and internal audit through the handover so they can test the framework independently.

How we support

Offer ongoing support under a retainer for the annual framework review, updates after major ICT incidents and supervisory feedback.
Support preparation of the review report your organization submits on request, with the content you approve.
Confirm with your competent authority and independent auditor which evidence they expect, since they, not DeployOpen, assess and report.