Delegated Regulation (EU) 2024/1774 ICT risk management RTS

What Delegated Regulation 2024/1774 asks ICT risk management teams to build

Delegated Regulation (EU) 2024/1774 is the Commission's technical standard that details the ICT risk management tools, methods, processes and policies required by DORA Article 15, and it also sets out the simplified framework that DORA Article 16(3) allows for smaller or less complex entities. If you are a compliance lead or CISO who must show that DORA ICT risk management works in practice, this regulation is the document an assessor will test you against. The risk it targets is familiar: security policies that exist on paper but are not applied, assets nobody has inventoried, changes deployed without review, and threats detected days after they could have been stopped. Its Title II, which applies to entities under the full framework, covers ICT security policies and tools, human resources and access control, incident detection and response, and ICT business continuity management.

The difficulty is less the depth of any single requirement than the number of them. The regulation asks for many small obligations, each with its own owner and frequency. Examples include reviewing accepted residual ICT risks at least once a year, running weekly automated vulnerability scans on assets supporting critical or important functions, reviewing network architecture and firewall rules at least every six months for those systems, and reviewing access rights every six months. Logging, clock synchronisation and log protection must work continuously. A control that is documented once but not operated on schedule will not survive an assessment, so the work is an operating rhythm, not a project.

Start by mapping every obligation in Title II to a named owner, a frequency and an evidence artifact, then confirm which of your systems support critical or important functions, because several frequencies apply only to them. Ask your team to show the last two cycles of each recurring activity, not only the policy text. Confirm with your competent authority or your legal advisers how the simplified framework applies to your entity before you choose it, since eligibility depends on your classification under DORA and on the proportionality principle in Article 1 of the regulation. The official text on EUR-Lex is the reference for the exact wording of each article.

Which entities, systems and third parties fall under the 2024/1774 full framework

Before any control is built, the scope of Delegated Regulation (EU) 2024/1774 has to be fixed. Whether an entity takes the full framework or the simplified one, which systems support critical or important functions, and who owns each area determine most of the work that follows.

Full framework or simplified framework

The first decision is whether the entity applies Title II, the full framework, or Title III, the simplified framework that Article 16(1) of DORA allows for qualifying entities. Title III is a lighter regime, but it still requires entities to test business continuity plans, including backup and restore, at least once a year or after every major change. Document the basis for the choice in the ICT risk management framework and have the management body approve it. Confirm eligibility criteria with your competent authority rather than assuming them.

Critical or important function mapping

Many frequencies in the regulation apply only to ICT systems that support critical or important functions. Weekly automated vulnerability scanning, six-monthly firewall rule checks and six-monthly access rights reviews all depend on this classification. Map each business service to the systems behind it, then tag the systems. An inventory that cannot show this link will leave you either over-testing low-value systems or missing obligations on high-value ones.

Group-level and shared systems

Identity platforms, logging pipelines, backup services and network segments are often shared across legal entities in a group. Decide which entity owns each shared system, how its controls are documented for each group member, and how reviews are evidenced for every entity that relies on it. Ask the group how intra-group ICT services are contracted and recorded, since these arrangements also feed the register of information. Shared ownership without written allocation is a common gap in assessments.

Outsourced and hosted systems

Self-hosted open-source platforms still sit inside scope when they run in a provider's cloud account or data center. The entity keeps responsibility for the controls, even where a provider operates the infrastructure. List each hosting arrangement, the systems it covers, and which logs, backups and access records the entity can obtain on request. Confirm with each provider what evidence it will supply for audits, such as log exports, access reports and restore test results.

Ownership across teams

The regulation assigns work to several functions that rarely share a backlog. IT operations typically owns asset inventory, patching and backup execution, security owns vulnerability management, logging and incident detection, HR owns joiner, mover and leaver processes for access, and business continuity owns recovery testing. Write a responsibility matrix that names one accountable owner per requirement. Without one, evidence gaps appear at the handoffs between teams.

Scope changes and reassessment

Scope is not fixed once it is set. New systems, acquisitions, migrations to new hosts and changes in the number of critical functions can move assets in or out of scope. Build a trigger list that prompts a scope review, and record the date and approver of each decision. Test the scope boundary with the same rigor as the controls, because an asset missing from the inventory is missing from every later review.

How an assessor tests ICT risk management under 2024/1774

This table compares the main control areas of Delegated Regulation (EU) 2024/1774 by test approach, evidence requested and common findings. Read each row as what a competent authority or independent assessor will ask to see, not only whether a policy exists. The main takeaway is that the regulation's specified review cycles and log and scan records must show operation over time.

Control area	Test approach	Evidence requested	Common findings
Security policies and framework review	Check that policies exist, are approved by the management body, and are reviewed on a defined cycle with the review outcomes recorded	Approved ICT security policy set, version history, review minutes, and the periodic framework review report	Policies written but never reviewed, or approval dated after the policy was already in use
Asset management	Sample assets and trace them to the inventory, then check that the inventory is kept current with changes	Asset register with owners and classification, change records showing additions and decommissioning, dependency mapping	Inventory missing self-hosted components, shadow services, or assets without a named owner
Residual ICT risk acceptance (Article 3)	Confirm accepted residual risks are recorded and reviewed at least once a year	Risk register entries, acceptance sign-offs by an accountable role, annual review records	Risks accepted once and never revisited, or acceptance made below the appropriate authority
Logging (Article 12)	Test which events are logged, retention settings, protection of log integrity, detection of logging failures, and clock synchronisation to a documented reference source	Logging procedure, retention configuration, samples of log output, access controls on log stores, time sync configuration and monitoring alerts for log gaps	Logs enabled on some systems only, no alert when logging stops, unprotected log stores, or clocks drifting from the documented source
Vulnerability scanning (Article 10)	Confirm weekly automated scanning covers assets supporting critical or important functions, then sample findings through remediation	Scan schedules, scan reports for recent weeks, tickets showing triage and fixes, exception approvals	Scans scheduled but failing silently, gaps in asset coverage, findings open with no owner or due date
Network architecture and firewall reviews (Article 13)	Check that network architecture and firewall rule reviews occur at least every six months for systems supporting critical or important functions	Review records with dates, rule-change tickets, firewall rule exports, sign-offs	Rule reviews done once at deployment, unused rules left in place, reviews not covering all segments
Access rights review (Article 21)	Select accounts for systems supporting critical or important functions and confirm rights match role and were recertified at least every six months	Access review records with dates, reviewer identity, removal tickets, privileged account lists	Leavers still holding access, reviews that approve everything without change, shared privileged accounts
ICT business continuity (Articles 24 to 26)	Review continuity plans, backup and restore procedures, and evidence of restore tests and their results	Continuity plan versions, backup job logs, restore test reports with timings and outcomes, lessons-learned records	Backups that have never been restored, plans not updated after major changes, test results without follow-up actions

Implementing the 2024/1774 framework in a sequence that holds up at audit

This sequence turns the requirements of Delegated Regulation (EU) 2024/1774 into a dated, owned set of artefacts that a competent authority or internal audit can trace from policy to operating record. Each step closes with an output the team can show, so gaps surface early rather than during supervision.

Confirm scope and the full or simplified path
The management body and compliance lead decide which entity or group entities the framework covers and whether the entity falls under the full framework of Title II or the simplified framework of Title III, which applies under DORA Article 16(1). They also record which systems support critical or important functions, because several frequencies in the RTS apply only to those systems. The output is a signed scope statement that names the regime, the entities in it and the list of in-scope systems. Confirm the path with your competent authority or legal counsel if the classification is contestable.
Approve security policies and the asset inventory
Security policies, procedures, protocols and tools under Articles 2 to 18 of the RTS need written approval by the management body before the controls they describe can be tested. In parallel, the asset owners build an inventory of hardware, software, data flows and dependencies, and map each asset to the functions it supports. The output is approved policy documents with version history and an asset register that the vulnerability scanner, backup inventory and access reviews can all reference. An auditor will check that the register and the policies agree.
Set the recurring review and scan schedules
Put the RTS frequencies into a calendar owned by named roles. Accepted residual ICT risks are reviewed at least once a year under Article 3, weekly automated vulnerability scanning applies to assets supporting critical or important functions under Article 10, and network architecture reviews and firewall rule checks run at least every six months for those systems under Article 13. In a self-hosted setup, configure the scanner, such as Greenbone Community Edition (OpenVAS), to run scheduled tasks and store results, and forward findings to a tracker such as DefectDojo for deduplication and ownership. The output is a schedule, scan configuration exports and a dated log of completed runs.
Configure logging and clock synchronisation
Article 12 requires documented decisions on which events are logged, how long logs are retained, how logs are protected against tampering, deletion and unauthorised access, and how logging failures are detected. All hosts in scope must synchronise to a documented, reliable reference time source. Configure this per system, for example by setting audit logging on self-hosted applications such as Nextcloud's admin_audit app, and confirm that log destinations are separated from the systems they describe. The output is a logging standard, a clock source record and test evidence showing that a sample event reaches the central store with a correct timestamp.
Run the first access and network reviews
Access rights for systems supporting critical or important functions must be reviewed at least every six months under Article 21, and the human resources and access control policy must cover joiners, movers and leavers. The first review establishes a baseline: owners certify each account, privileged accounts are justified, and orphaned or shared accounts are removed or documented. Pair this with the first network architecture review and firewall rule check under Article 13. The output is signed review records with the reviewer, date, decisions taken and tickets closing each exception.
Test business continuity, including backup and restore
Business continuity management under Articles 24 to 26 requires plans that are tested, and entities under the simplified framework must test plans, including backup and restore procedures, at least once a year or after every major change under Article 40. Run a restore of a representative system into an isolated environment, measure whether it meets the recovery objectives in the plan, and record what failed. The output is a test report with scenario, participants, results, defects and the owner and date of each corrective action. Retain the report with the plan version it tested.
Produce the framework review report
Article 27 requires a report on the review of the ICT risk management framework, which consolidates the preceding steps. It should state what changed since the last review, which incidents, scan findings, access exceptions and test results drove changes, and what the management body approved or deferred. Assign each open action an owner and a date. The output is a signed report that links to the policies, schedules, logs and test records produced earlier, so that an assessor can follow any claim back to evidence.

Evidence that passes for logging, scanning, access and continuity

Delegated Regulation (EU) 2024/1774 asks for controls that run continuously, so assessors look for records that show the control operated over time, not a single snapshot. The six artifacts below cover the policy, asset, scanning, access, logging and continuity areas, and each one needs dated exports, change history and a named reviewer to stay credible between audits.

Approved policy versions with sign-off

Keep each ICT security policy and procedure under version control, with the approving body, the date of approval and the reason for each change. Assessors check that the management body approved the current version and that the review cycle was followed, not just that a document exists. Export the approval record with the document hash so the signed version can be shown later. Confirm with your own governance team which policies must be approved by the management body and which can be approved at a lower level.

Asset inventory with ownership and dependencies

The inventory should list every ICT asset, its owner, its location and the critical or important functions it supports. Assessors trace a sample of assets back to the functions they support, so dependencies matter as much as the list itself. Record when the inventory was last reconciled against discovery data and who signed off the reconciliation. Ask your team to confirm how cloud resources and self-hosted containers are captured, since gaps usually appear there.

Scan schedules and result exports

For assets supporting critical or important functions, the RTS expects weekly automated vulnerability scanning. Keep the scan schedule export, the task history and dated result exports that show each scan ran and how findings were triaged. Store the scanner configuration alongside the results so an assessor can see which checks were enabled. Track findings through to remediation or accepted risk, because a list of open findings without decisions is a weak record.

Access review records for critical systems

Access rights for systems supporting critical or important functions must be reviewed at least every six months. The evidence is a dated review record listing each account, its entitlements, the reviewer's decision and the removals made. Keep the reviewer's name, the review ticket and proof that revoked accounts were actually disabled. Confirm with your identity team whether service accounts and privileged roles are included in the same review cycle.

Logging configuration with retention and tamper protection

Article 12 expects a documented list of events to log, defined retention periods, protection against tampering and deletion, detection of logging failures, and clock synchronization to a documented reference time source. Export the effective configuration and the retention settings, and show the access controls on the log store. Keep alerts that fired on logging failures and the time sync records. Confirm the retention periods with your compliance owner, because the RTS sets the need for a defined period rather than a single number.

Continuity test records with backup and restore

Business continuity plans need tests, including backup and restore procedures. For entities under the simplified framework, Article 40 sets an annual test or a test after every major change. Keep the test plan, the scenario, the restore timings measured against your recovery objectives, the defects found and the retest evidence. An assessor will look for a restore that was actually performed, not only a backup job that reports success. Ask your operations lead to confirm the recovery objectives that each test is measured against.

What meeting 2024/1774 costs in money and effort

This table compares the main cost components of meeting the 2024/1774 ICT risk management requirements, who is paid for each, whether it is one-time or recurring, and what to request in a quote. No prices or durations are given because none are supplied, so use the drivers and quote items to compare proposals. Open-source tools can remove licence spend, but the labour to configure and run them remains.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to request in a written quote
Tooling and licences	Mostly recurring if commercial. Open-source tools such as Greenbone Community Edition, DefectDojo and CISO Assistant remove licence spend but not setup or hosting labour.	Number of in-scope assets, existing scanner or GRC tooling, and whether tools are self-hosted inside the entity's own infrastructure.	Itemized list of every tool, licence model, hosting location, and which components are open source with their licence terms.
Engineering time for logging and clock sync	One-time build, then recurring tuning. Paid to internal engineers or an implementation partner.	Number of log sources, retention periods set under Article 12, and whether a documented reliable time source already exists.	Log source inventory, retention schedule, tamper protection design, logging failure alerts, and time source documentation.
Engineering time for vulnerability scanning and network reviews	One-time setup, then recurring weekly scans and six-monthly firewall and architecture checks for critical or important functions.	Number of systems supporting critical or important functions, network complexity, and how many findings require manual triage.	Scan scope list, scan schedule, credentialed scan approach, review workflow, and evidence retained for each review cycle.
Access rights review and identity controls	Recurring effort every six months for in-scope systems, paid to internal staff or a partner.	Number of accounts, identity sources, and how many systems lack central identity integration.	Access review procedure, sample evidence of a completed review, and the list of systems included.
Business continuity and backup testing	Recurring. Simplified framework entities must test at least yearly or after major change (Article 40). Paid to internal staff or a partner.	Number of critical systems, restore complexity, and whether restores have been tested before.	Test plan, restore success criteria, test records, and the cost of any test environment.
External penetration or security testing	Recurring, paid to an independent tester. Not a DORA attestation, which applies only to TLPT under Article 26(7).	Application and infrastructure footprint, number of in-scope systems, and retesting after remediation.	Defined scope, methodology, rules of engagement, report format, and retest terms.
Independent review and internal assurance	Recurring. Paid to an external reviewer or internal audit to check the framework against 2024/1774.	Maturity of existing documentation, group structure, and whether control owners already produce evidence.	Review scope, sampled controls, deliverables, and whether findings are tracked to closure.
Auditor or competent authority sampling	Recurring as supervision requires. Paid to the entity's own assessor or internal staff to prepare evidence, since only independent auditors or supervisors issue conclusions.	Number of entities in a group, how evidence is stored, and how quickly records can be produced.	Evidence index mapping each Article to its artifact, owner, and retention location.
Group structure and shared services	Mixed. Shared frameworks are one-time, while entity-level evidence is recurring.	Number of legal entities, shared versus local tooling, and differences between sites.	Whether the quote covers group-wide design, entity-level deployment, and separate evidence per entity.

Self-hosted tools that produce parts of the 2024/1774 evidence

Four self-hosted open-source tools can generate or hold records that support parts of Delegated Regulation (EU) 2024/1774, covering framework mapping, findings management, vulnerability scanning and audit logging. Each produces evidence only within the process the organization designs and runs, and none of them makes the organization compliant on its own.

Framework mapping with CISO Assistant

CISO Assistant (AGPL-3.0-only) ships a DORA framework and can record controls, assessments and audits against it, which gives the compliance team one place to show how each ICT risk management article maps to a policy, a control owner and a test result. Confirm that the DORA framework version loaded matches the text you are assessing against, and check whether the mapping between frameworks is one your team has reviewed before relying on it for DORA evidence. The tool holds the register; the organization still writes the policies and decides what each control means for its own entity.

Findings deduplication with DefectDojo

DefectDojo (BSD-3-Clause) imports findings from scanners, penetration tests and other tools, then deduplicates them using per-tool hashcode fields, so a single weakness reported by several tools appears once with its history. That history supports the remediation tracking Article 10 expects for vulnerability handling. Confirm which of your scanners have a supported parser, use the generic import for the rest, and agree how severity and remediation deadlines are set, because the tool records what it receives and does not judge risk.

Scheduled scanning with Greenbone

Greenbone Community Edition (AGPL-3.0-or-later) runs through gvmd, which stores results in PostgreSQL, manages users and permissions and schedules scan tasks that analysts review in the Greenbone Security Assistant. Scheduled tasks and stored results can show that scanning of assets supporting critical or important functions happens at the frequency your policy sets. Confirm the scan targets cover every in-scope asset, configure a weekly schedule for those systems, and keep exports of the results, since the scanner records what it finds but does not decide which findings are accepted risks.

Access and audit trails with Nextcloud

The admin_audit app in Nextcloud (AGPL-3.0-only) writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Those entries can support the logging and access review evidence Article 12 and Article 21 call for on a file-sharing platform. Confirm the audit log path sits on protected storage, set retention and forwarding in line with your logging procedure, and verify that logging failures and clock synchronization are monitored at the host level, because the app alone does not cover those duties.

Who owns, who implements and who assesses each part of the RTS

Your organization owns the ICT risk management framework under Delegated Regulation (EU) 2024/1774. The management body must approve the framework, and nothing an outside party prepares replaces that accountability. Your team decides which risks are accepted, signs off the policies, and runs the periodic framework review. The regulation expects the review to be documented and to feed back into the framework, so the decisions and their reasons must be recorded in your own records.

Policies and approval: Your team writes or adopts the security policies, procedures and tools, and the management body approves them.
Risk acceptance: Your team decides which residual ICT risks are accepted, and reviews those acceptances at least once a year.
Operating ownership: Staff who run access reviews, log reviews, vulnerability triage and change approvals are your employees or your contracted staff acting under your direction.
Framework review: Your team prepares the report on the framework review and records the improvements that follow.
Vendor oversight: Your team keeps accountability for any service provider used to run controls.

Confirm with your compliance lead which named roles hold each decision, and whether your competent authority expects a specific sign-off record.

An implementation partner such as DeployOpen can plan, configure and document the technical controls that the RTS describes, and can prepare the evidence those controls generate. Work of this kind is usually fixed-scope and agreed in writing before it starts. The partner does not decide which risks you accept, does not approve policies in place of your management body, and does not issue any audit report, attestation or certification. DeployOpen prepares systems and evidence; independent assessors reach their own conclusions.

Logging configuration: Setting event sources, retention periods, tamper protection and clock synchronization against a documented reference time source, such as the settings for admin_audit in Nextcloud.
Scan schedules: Configuring weekly vulnerability scans for assets supporting critical or important functions and storing results for triage.
Network and access artifacts: Preparing firewall rule exports, access rights reports and the records needed for the six-monthly reviews.
Evidence packs: Assembling screenshots, configuration exports, ticket trails and test outputs in a structure your assessor can follow.
Test support: Preparing systems for penetration and continuity tests and documenting the results for your team to act on.

Before engaging a partner, ask for the written boundary of its role and confirm that your team, not the partner, signs every decision and approval.

How much effort, time and internal capacity does 2024/1774 require?

Which parts of 2024/1774 take the most effort to implement?

The heaviest work sits in Title II, which applies the full framework to entities that do not use the simplified route. It covers ICT security policies and tools (Articles 2 to 18), human resources and access control (Articles 19 to 21), incident detection and response (Articles 22 and 23), and ICT business continuity management (Articles 24 to 26). Effort rises with the number of in-scope systems, the number of ICT services that support critical or important functions, and how complete current asset records and log retention settings are. Much of the work is recurring: weekly automated vulnerability scanning for those assets (Article 10), network architecture review and firewall rule checks at least every 6 months (Article 13), and access rights review every 6 months (Article 21). Ask any provider to split the effort into one-time build work and these recurring cycles.

Can an in-house team meet 2024/1774 without outside help?

An in-house team can do this work, and many institutions do. The constraint is usually capacity and skills across security engineering, IT operations, risk, compliance and continuity, not technical tooling. Before deciding, check whether your team already runs weekly scanning with documented follow-up, enforces log retention and protects logs against tampering and deletion (Article 12), keeps clocks synchronised to a documented reliable reference time source, and completes six-monthly access reviews. Gaps tend to appear in evidence production: consistent records, dated approvals and reproducible test results. Confirm your scope and the expected depth of evidence with your competent authority and internal audit before you commit staff time.

What does management and system ownership need to provide for 2024/1774?

The management body must approve and oversee the ICT risk framework, and it needs enough detail to make decisions rather than sign a summary. Asset owners must keep inventories current and confirm which systems support critical or important functions. System owners must take part in access reviews, approve changes, and run business continuity exercises for their services. Under the full framework, the annual review of accepted residual ICT risks (Article 3) needs a named owner with authority to accept or reject risk. In practice, expect recurring calendar commitments from these owners for the life of the framework, not a one-off sign-off. Writing these roles and their cycles into a schedule before work starts makes the later effort far easier to estimate.

How does the simplified framework change the effort under 2024/1774?

The simplified framework sits in Title III (Articles 28 to 41) and applies to entities that qualify under Article 16(1). It reduces the scope of obligations, but it does not remove the need for a documented framework and evidence. One concrete requirement is stated in the text: Article 40 requires entities under the simplified framework to test business continuity plans, including backup and restore procedures, at least once every year or upon every major change. Eligibility is the first decision, and it depends on your entity type and risk profile, so confirm it with your competent authority before reducing your plan. Compare the Title III articles line by line against your current controls to see which full-framework activities you can drop and which still apply.

Can a partner take over the ongoing evidence upkeep for 2024/1774?

A partner can prepare and maintain the systems that produce evidence, but the organization still owns its controls and decides what they say. Self-hosted open-source platforms can support this work inside your own infrastructure. Greenbone Community Edition (OpenVAS) consolidates vulnerability scanning, stores results in PostgreSQL and schedules scan tasks, which supports the weekly scanning cycle. DefectDojo imports findings from many tool report formats and deduplicates them, which helps keep remediation records traceable. For logging, Nextcloud's admin_audit app writes to audit.log in the data directory or to a path set with logfile_audit. Recurring upkeep is usually scoped as a retainer for support, upgrades and continuous testing, separate from the initial build. No independent auditor is replaced by this work.

How do I request a quote for 2024/1774 work from a written scope?

DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To get comparable quotes from any provider, ask for the entities and in-scope systems covered, the articles of the RTS addressed, the evidence each deliverable will produce, and which owner roles the provider expects you to fill. Request a split between one-time build work and recurring activities such as scanning cycles, access reviews and continuity tests, along with retainer terms if ongoing support is included. List assumptions and exclusions explicitly, including what the provider will not do, such as issuing audit reports, which only independent auditors and certification bodies can do.

How DeployOpen scopes, implements and prepares evidence for 2024/1774

DeployOpen works on Delegated Regulation (EU) 2024/1774 as an implementation partner. We map the ICT risk management requirements to your self-hosted open-source platforms inside your own infrastructure, build the controls and evidence, and document them for your team and your independent auditor or competent authority. The organization owns its controls and its compliance position.

How we scope

Engagements are fixed-scope, with the systems, Article 15 policies and Article 16(3) simplified framework choice agreed in writing before work starts.
The written scope lists which platforms, logs, scanners and continuity processes are in and which Title II or Title III articles apply to your entity.
We confirm with you which systems support critical or important functions, since several 2024/1774 frequencies depend on that classification.

How we build

We deploy and harden open-source tooling in your cloud accounts, data centers or air-gapped networks, configuring logging, scanning and access review workflows.
We configure log retention, tamper protection and a documented reliable time source, so Article 12 evidence is produced by the platform itself.
We set up vulnerability scanning and findings tracking, including weekly scans for critical or important assets where the scope requires them.

How we hand over

We document policies, procedures, configurations and runbooks, and map each deliverable to the article it supports in the agreed scope.
We deliver evidence packs such as scan reports, access review records, firewall rule checks and continuity test results for your assessors to examine.
We walk your security, IT and compliance teams through operation so ownership of controls and evidence stays with your organization.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so frequencies such as the six-month access review keep running after handover.
We can review changes to systems and policies against the agreed scope when your environment or the regulation's review process changes.
Ask us to confirm in the quote how support hours, upgrade responsibilities and evidence refresh cycles are priced and who performs each task.