What DORA requires for data and endpoint security, and who owns it
A financial entity in scope of DORA must show that its devices, data and teleworking arrangements meet Articles 11 and 14 of Delegated Regulation (EU) 2024/1774. The organization owns these controls and answers for them to its competent authority. No authority, auditor or vendor issues a DORA certificate for them, so the evidence the firm keeps is its own record of how each control is designed, operated and reviewed. An implementation partner can prepare configurations, deployment records and test results, but the decisions on what each device class may do remain with the entity's management body and security function.
The answer differs by device fleet, data classification, third-party use and teleworking model. A firm with managed corporate laptops and no personal devices faces a different set of decisions from one where staff use private phones for email, or where a cloud provider holds customer records. Before writing any baseline, the entity should confirm which devices can reach data supporting critical or important functions, which data classes those devices may hold, and which external services sit in the teleworking path. Article 9 sets the background duty: the entity must protect data at rest, in use and in transit, and must continuously monitor and control the security of its ICT systems, with extra attention to systems supporting critical or important functions.
Start with an inventory that maps device types to data classes and to the business functions they support. Then confirm, with the entity's own risk assessment and classification scheme, which combinations are acceptable and which need compensating controls. Ask the vendors and any managed service provider in the chain to state in writing which of the baseline settings, remote wipe features and deletion methods they support and how they are verified. Where a capability is unclear, record it as an open item rather than assuming it exists.
Which DORA endpoint and data duties apply to which device
DORA's endpoint and data duties sit in Article 11 and Article 14 of the ICT risk management RTS, with Article 9 of the Regulation setting the baseline. Each card below covers one duty, the device or data it applies to, and what an assessor will ask to see.
Secure configuration baselines
Every ICT asset that supports the entity's operations needs a documented secure configuration baseline, and Article 11 requires that the configuration be verified regularly rather than assumed. In practice, the baseline is a written standard for each device class and operating system, with a recurring check that live systems still match it. Ask who owns the baseline, how often verification runs, and where deviations are recorded and fixed.
Authorised software, media and endpoints
Article 11 allows only authorised software, storage media and endpoints to access the entity's systems. The entity must maintain an approved list and a way to block or flag anything outside it, including removable media and personal devices. Check whether the approval list is tied to the asset inventory and whether exceptions have a named approver and an end date.
Malware protection measures
Article 11 requires measures against malware on endpoints and systems. The control is not only a scanner: it covers signature and behavioural detection, restricted execution, and alerting that reaches a responsible team. Ask which tool covers each device class, how coverage gaps are found, and how detections feed into incident handling.
Remote management and wipe
Article 11(2) requires portable and private endpoints used for work to be remotely managed and remotely wipeable. This matters most for laptops, phones and personal devices that hold or reach entity data. Confirm that enrolment is a condition of access, that wipe can be triggered without the user's cooperation, and that the entity can show a record of each wipe.
Secure deletion and disposal
Article 11(2) requires processes for secure deletion of data and secure disposal of ICT assets. Deletion must reach backups, replicas and decommissioned storage, not only the primary copy. Ask for a documented method per media type, a record of disposal or destruction, and a check that retired assets were removed from the inventory.
Data loss prevention
Article 11(2) requires data loss prevention processes. These controls watch for sensitive data leaving approved channels, such as email, cloud uploads, removable media and printing. Confirm which data classes the rules cover, who reviews alerts, and how false positives are tuned so that staff do not route around the controls.
Teleworking and third-party security
Article 11 requires the entity to set security requirements for teleworking and for the use of ICT third-party services. Remote access rules should cover the home network, shared devices and the handling of printed or stored data outside the office. Confirm that the same requirements apply to contractors and that third-party services that touch endpoints are listed in the register of information.
How secure configuration baselines and remote wipe work in practice
A secure configuration baseline is a written, agreed set of settings that each endpoint must have before it is trusted with work data, such as disabled legacy protocols, enforced screen locks, disk encryption, restricted local administrator rights and an approved list of software. Article 11 of Delegated Regulation (EU) 2024/1774 expects the entity to verify that baseline on a schedule rather than only at build time, and to block software, storage media and endpoints that are not on the approved list. In practice, the first decision is who owns the baseline: the platform team usually writes it, the security function approves it, and the risk owner accepts any deviations in writing. Confirm how often your own risk assessment sets the verification interval, because the Regulation leaves that choice to the entity.
Wazuh's Security Configuration Assessment (SCA) module is one way to run that check on monitored endpoints. It evaluates each agent against YAML policy files, most of which are based on CIS benchmarks, and it can read files, directories, registry keys and running processes. Each failed check comes with a remediation recommendation, which your team can convert into a ticket with an owner and a deadline, and a custom policy can express your own baseline where the shipped policies do not match it. Check the policy coverage for each operating system in your fleet before you rely on it, and record any check you disable, since an auditor will ask why it was excluded. The Wazuh SCA documentation lists the supported checks and how policies are loaded.
Remote management and remote wipe apply to portable and private devices used for work, including laptops, phones and tablets that staff bring into their own routine. Article 11(2) requires them to be remotely managed and remotely wipeable, so the organization must decide which personal devices may access corporate data and enroll them in mobile device management or an equivalent. An agent-based scanner cannot inspect a device it does not run on, so unmanaged personal devices fall outside SCA coverage and need a different control, such as blocking access from them. Confirm with your own environment which endpoints the tool can reach, which it cannot, and what the wipe procedure is when a device is lost or an employee leaves.
How the rules differ for corporate, portable and private devices
Desktops and workstations that stay in the office or in a managed facility are the simplest case. The organization owns them, controls their build and can enforce a secure configuration baseline across the fleet. Article 11 expects that baseline to be defined, applied and verified regularly, and that only authorised software, storage media and endpoints connect to the environment. Malware protection and the rules on removable media sit on the same fleet.
- Baseline definition: A documented hardening standard per device image, with named owners and a review date.
- Verification: Scheduled configuration scans against that baseline, such as a Wazuh Security Configuration Assessment policy extended with the organization's own checks.
- Software and media control: Allow-lists for applications and rules for USB or other removable media, enforced on the device.
- Malware protection: Endpoint protection that is installed everywhere, reports centrally and is monitored for disabled or out-of-date agents.
- Evidence to keep: Baseline documents, scan results over time, exception approvals and remediation tickets.
A practical gap is a baseline that exists only as an image built once, with no regular verification and no record of who approved exceptions. Confirm which fleet tooling produces the scan evidence and how often it runs.
Laptops, tablets and phones owned by the organization leave the premises, so the controls must travel with them. Article 11(2) requires portable endpoints used for work to be remotely managed and remotely wipeable, and it requires processes for secure deletion and secure disposal of ICT assets. The baseline still applies, but the organization must also be able to reach the device when it is off-network.
- Remote management: Every portable device enrolled in mobile or endpoint management before it holds business data, with the ability to push policy when it is outside the corporate network.
- Remote wipe: A tested wipe capability, including the steps taken when a device is lost, stolen or not returned, and who can trigger it.
- Encryption at the device level: Full-disk or device encryption enforced and reported by the management platform, coordinated with the encryption policy.
- Secure disposal: A written process for wiping or destroying storage before reuse, resale or return to a supplier, with certificates or logs kept.
- Evidence to keep: Enrollment reports, wipe test records, loss and theft tickets, and disposal certificates.
A common gap is a device fleet where wipe has never been tested and the disposal process is handled informally by facilities staff. Ask the platform team to demonstrate a wipe on a test device and to produce the disposal record for the last device retired.
Bring-your-own-device arrangements are where ownership, control and contract terms diverge. The organization does not own the hardware, so it cannot apply the same baseline or disposal rules without the employee's agreement. Article 11(2) still expects private endpoints used for work to be remotely managed and remotely wipeable, so the organization needs a policy, a technical enrolment method and a contractual basis for the wipe. The organization must confirm its own policy on private devices and how its employment and contractor agreements handle wiping, because those terms decide what it can lawfully do.
- Policy decision: A written decision on whether private devices may access business data at all, and for which data classes.
- Containerisation: Separation of work data and applications from personal data, so that a selective wipe removes only business content where the platform supports it.
- Consent and contract terms: Signed acknowledgment that the organization may wipe the work container, and an explanation of what a full wipe would remove.
- Labour and privacy review: Confirmation with legal and the data protection officer that monitoring and wiping are proportionate and lawful in each member state.
- Evidence to keep: Signed device agreements, enrolment records, selective wipe tests and records of any wipe carried out.
A practical gap is a BYOD policy that allows email on personal phones with no enrolment, no wipe method and no signed agreement. Confirm with counsel how wiping terms apply to contractors who use their own equipment.
Some devices and data sit outside the organization's direct control, including devices operated by ICT third-party services and staff devices managed by a contractor. The RTS also requires the entity to set security requirements for teleworking and for the use of ICT third-party services. The split of responsibility should therefore be visible in both the internal policy and the contract, so that an assessor can trace each device class to an owner and an enforceable obligation.
- Responsibility matrix: A table listing each device class, its owner, the baseline that applies and the party that performs wipe and disposal.
- Teleworking rules: Written requirements for home networks, screen privacy, public Wi-Fi and the storage of business data locally.
- Provider clauses: Contract terms that require providers to support wipe, disposal evidence and incident notification for their devices.
- Review cycle: A scheduled check that the matrix still matches the fleet and the contracts still reflect it.
- Evidence to keep: The signed matrix, teleworking standard, relevant contract clauses and review minutes.
If a provider's staff access the environment from their own laptops, check the contract before assuming the organization's wipe rights extend to them. Confirm these terms with your procurement and legal teams.
How an assessor tests endpoint and data controls
The sequence starts with the documented rules and the asset inventory, then tests whether those rules hold on real devices and real data flows. Each step closes with a record the organization can hand over, so the assessor can trace a policy to a configuration, a device and a deletion or wipe event.
Review the policy and asset inventory
The assessor first reads the ICT security policy, the endpoint and media rules, and the teleworking and data loss prevention requirements, then checks them against the asset inventory. The question is whether every portable device, private device used for work, storage medium and endpoint class is recorded and mapped to an owner. Have ready: the approved policy version with its approval record, and an inventory export showing device type, owner, classification of data accessed and management status. Confirm the inventory is current on the day the assessment starts, since gaps here undermine every later sample.
Sample devices from the inventory
The assessor selects a sample of devices from the inventory, including corporate laptops, mobile devices, removable media and at least some private devices used for work, and confirms each sampled device is enrolled in the management tooling the organization claims. The assessor then checks that only authorised software and storage media appear on the device. Have ready: enrollment records, the software approval list, and a short explanation of how the sample was chosen so the selection is reproducible. Samples drawn only from devices the organization already knows are weaker evidence, so ask the assessor how they will reach the rest.
Check baseline scan results and exceptions
For the sampled devices and their asset classes, the assessor reviews the secure configuration baseline and the results of the most recent scans against it. Open-source tools such as Wazuh Security Configuration Assessment can produce these results from YAML policies that check files, directories, registry keys and running processes, and recommend remediation. The assessor looks for regular verification, not a one-time hardening run, and for every failed check either a remediation record or an approved exception. Have ready: the baseline document, scan reports with dates, the policy files used, and the exception register.
Test a remote wipe or disposal record
The assessor picks one or more devices that were lost, retired, reassigned or left the organization and asks for proof that data was removed. For portable and private endpoints used for work, the expected evidence is a remote wipe command and its confirmation, or for disposal, a secure deletion or destruction record tied to the asset identifier. The assessor then checks that the wipe or deletion matches the inventory entry. Have ready: the management console log entry for the wipe, the timestamp and operator, the asset disposal form, and any certificate from a disposal provider. Where a private device could not be wiped, the record should show the compensating control and who approved it.
Review DLP and teleworking configuration
The assessor reviews the data loss prevention rules and teleworking requirements together, since both govern how data leaves the organization and how staff reach it from outside the office. The assessor checks which data classes the DLP rules cover, which channels (email, web upload, removable media, cloud sync) they monitor, and whether the teleworking standard sets requirements for devices, network access and handling of data outside the premises. The assessor also checks that security requirements are set for ICT third-party services used in teleworking. Have ready: DLP rule sets with their scope, alert handling records, the teleworking standard, and the list of approved external services with their assessed requirements.
Confirm the owner approved any exception
As the final check, the assessor traces every exception found in the earlier steps back to a named owner and a documented decision. An exception is acceptable only when the owner accepted the residual risk in writing, the reason is recorded, and the exception is reviewed on a set cycle that the organization defines. The assessor will look for exceptions that were never approved, approvals given by the person who runs the system, and exceptions that stayed open after the risk changed. Have ready: the exception register with approver names and dates, the risk acceptance forms, and the review records showing each exception was revisited.
What must be in place before an assessment of endpoint controls
An assessor testing DORA data and endpoint controls will ask for evidence that the baseline, device list, wipe process and teleworking rules exist and are followed. The cards below cover the six items to have in place first, and how to check each one against what the entity actually runs.
Approved device and software list
Article 11 of Delegated Regulation (EU) 2024/1774 allows only authorised software, storage media and endpoints, so the entity needs a written allowlist before any test. Check that the list names approved operating systems, applications, removable media and personal devices permitted for work, and that each entry has an owner and an approval date. Ask for evidence that unapproved software is blocked or detected, not just prohibited in policy. The allowlist must match what is actually running on sampled endpoints.
Current asset inventory with owners
An endpoint control is only testable if the assessor can tie a device to a named owner and a business function. Check that the inventory covers laptops, mobile devices, servers and private devices used for work, and that each record links to a responsible person and to the ICT services it supports. Sample a handful of devices from the network and confirm each one appears in the inventory. Stale records for leavers or retired devices are a common finding.
Baseline definitions and verification schedule
The entity needs a secure configuration baseline for each device class, along with a schedule that says how often the baseline is verified. Check that the baseline is versioned, approved by someone accountable, and mapped to the device types in the inventory. Ask for the most recent verification results and the remediation tickets raised from them. Automated configuration assessment tools such as Wazuh can produce these results, but the entity must show that the policies it runs reflect its own baseline.
Remote wipe and disposal process with records
Article 11(2) of Delegated Regulation (EU) 2024/1774 requires portable and private work endpoints to be remotely managed and remotely wipeable, and requires processes for secure deletion and secure disposal. Check that the procedure names who can trigger a wipe, how it is tested, and how private devices are handled when an employee leaves. Ask for disposal certificates or logs for a sample of retired devices. The wipe record should show the device, the date, the requester and the confirmation that the wipe completed.
Data loss prevention rules
Article 11(2) also requires processes for data loss prevention, which means the entity has defined what data must not leave its control and how that is enforced. Check that the rules cover email, web uploads, removable media, cloud sync and printing, and that each rule maps to a data classification level. Ask for the alert history and the response records for recent blocked transfers. Rules that exist only as a policy document give an assessor little to test.
Teleworking standard and third-party clauses
Article 11 requires security requirements for teleworking and for the use of ICT third-party services. Check that the teleworking standard covers approved networks, device posture, screen privacy and home office storage, and that it is signed off by management. For third-party providers that touch endpoints or data, check that contracts include security clauses, audit rights and incident notification duties. Ask for the signed contract clauses for the top providers, since a generic reference to security in a contract is unlikely to satisfy an assessor.
What drives the cost of endpoint and data remediation
This table breaks the effort behind DORA endpoint and data remediation into its cost components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a request for an itemized written scope, since no figures are given here and every estimate should come from your own environment.
| Cost component | Who is paid or who carries it | One-time or recurring, and main driver |
|---|---|---|
| Internal staff time for policy and asset inventory | Your own IT, security and compliance staff | One-time to build the baseline and device inventory, then recurring upkeep. Driver: number and variety of endpoints, including private and portable devices used for work |
| Licensed management and scanning tools | Software vendors, through licence or subscription fees | Recurring. Drivers: endpoint count, whether remote wipe and configuration scanning are included, and whether tools are open source or commercial |
| Implementation partner work on baselines and wipe workflows | External implementation partner, under a written fixed scope | One-time for configuration, hardening and wipe workflow design, with optional retainer support afterwards. Driver: number of device platforms and integration with existing management systems |
| Secure deletion, disposal and data loss prevention setup | Internal staff, and any disposal or data handling provider you use | Mostly one-time for procedures and rules, with recurring disposal work. Driver: volume of retired assets and the data classes involved |
| Testing of configurations, wipe and teleworking controls | Internal testers or an independent tester, under a written scope | One-time for initial validation, then repeated after major changes. Driver: how many baseline and remote access paths must be exercised |
| Verification and exception handling | Internal security operations staff | Recurring. Drivers: frequency of baseline checks, number of approved exceptions, and how quickly deviations are reviewed and closed |
| Teleworking rules and third-party service requirements | Internal legal, HR and procurement staff, plus advisers if engaged | One-time to set requirements, then recurring review when new ICT third-party services are adopted. Driver: how many remote access and external services are in use |
Questions teams ask about DORA endpoint and data security
Must private devices used for work be remotely wiped under DORA?
Yes, when a private device is used for work with entity data, Article 11(2) of Delegated Regulation (EU) 2024/1774 expects it to be remotely managed and remotely wipeable. The same applies to portable endpoints used for work. The practical question is scope: which private devices access corporate systems, mail or data. Teams usually answer this through a mobile device management or containerization approach that separates work data from personal data, so that wiping removes only the work partition. Confirm with your legal and HR functions how staff consent to remote wipe and how personal data is protected during the process, since that depends on your employment rules and GDPR obligations.
What does a secure configuration baseline need to cover?
A secure configuration baseline defines the approved settings for each class of ICT asset, and the entity must verify those settings regularly. Article 11 of Delegated Regulation (EU) 2024/1774 sets this expectation alongside controls that allow only authorised software, storage media and endpoints. In practice, a baseline covers operating system and application hardening, service and account settings, logging and malware protection settings, and the files, directories, registry keys and running processes that matter for each asset type. Each baseline should name an owner, a source it was derived from, and the exception process. Your own risk assessment should decide which assets are in scope and how often verification runs.
Does using Wazuh satisfy the DORA configuration requirement?
No single tool satisfies DORA, but Wazuh can produce evidence for part of the requirement. Its Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, most of which are based on CIS benchmarks and can be extended with custom policies. It checks files, directories, registry keys and running processes and recommends remediation, which supports the regular verification of a baseline. The entity still has to define the baseline, decide the approved software list, document exceptions, and show that findings are acted on. Confirm the current policy coverage for your operating systems in the Wazuh documentation before relying on it, and confirm the license terms (GPL-2.0-only) with your legal team.
How do teleworking rules differ by role?
Teleworking rules under Article 11 of Delegated Regulation (EU) 2024/1774 must be set as security requirements, but the entity decides how they vary. The usual approach ties the access level to the role: staff with privileged or access to critical or important functions may need managed devices only, network access restricted to specific paths, and session controls, while standard staff may use a narrower set of applications. Contractors and third-party staff often need separate rules that match their contracts. Document each role, the devices and locations permitted, and the approval path for exceptions. Review the rules when roles change, and record which ICT third-party services teleworkers depend on.
What must our organization do itself, and what can we outsource?
The organization owns its controls and must make the decisions: which assets are in scope, what the approved software and baseline are, which teleworking rules apply, and who accepts residual risk. Those decisions sit with management and cannot be delegated to a consultant or tool. An implementation partner can prepare systems, deploy and configure tooling, document baselines and collect evidence, within a written scope. Independent auditors or assessors test the result and issue any reports. Ongoing monitoring, patching and tool upkeep can be retained as a service, but the entity must still review the outcomes. Ask any provider to state in writing which deliverables it produces and which decisions remain with you.
What drives the effort to meet these requirements?
Effort depends mainly on the size and variety of the estate, the number of device types and operating systems, and how many devices are personal rather than corporate. Other drivers include how mature your asset inventory is, whether baselines already exist, how many exceptions and legacy systems there are, and how much integration is needed with identity, mobile management, backup and logging platforms. Data loss prevention and secure deletion add work when data classification is incomplete. For a quote, ask the provider to break effort down by asset group, state what is one-time (design, deployment, policy writing) and what recurs (verification, patching, reviews), and list the assumptions about your environment.
Who verifies that our endpoint and data controls comply?
Competent authorities supervise DORA compliance for financial entities, using the powers in Article 50 of the Regulation. Within the entity, internal audit and management oversight check that controls work. Independent auditors or assessors may test controls when a contract, client or regulator requires it, and only they issue reports or attestations. DeployOpen prepares systems, controls and evidence for those assessments but does not issue audit reports or certifications. Confirm with your supervisor which evidence it expects for endpoint baselines, remote wipe logs and teleworking approvals, because supervisory expectations and assessment approaches can differ by entity type and member state.
Who owns the controls, who prepares evidence, and who assesses them
The organization owns its endpoint controls. Its management body approves the ICT risk management framework, its ICT function sets the secure configuration baseline, the list of authorized software and media, and the teleworking rules, and its named risk owners accept any residual risk. An implementation partner such as DeployOpen can plan, configure, document and test these measures inside the organization's own environment, but it cannot take over the decisions. The sign-off on each baseline and each teleworking rule stays with the entity, and the entity should be able to show who approved what and when.
Evidence is prepared in two layers. The partner or internal engineers build the technical records: baseline configurations, scan results from a tool such as Wazuh's Security Configuration Assessment, device enrollment and remote wipe records for portable and private devices, deletion and disposal logs, and data loss prevention alerts. The organization then checks that those records match its written policy and keeps them under its own governance. Ask any partner to state in writing which records it will produce, where they will be stored, and who is responsible for reviewing them.
DORA sets no certification scheme, so no body issues a DORA certificate for endpoint controls. Competent authorities supervise compliance using their powers under Article 50, and independent auditors may test the controls as part of the entity's own assurance program, but neither issues a DORA attestation for baselines or remote wipe. The only authority-issued attestation the Regulation provides for concerns threat-led penetration testing under Article 26(7). Confirm with your supervisor and internal audit function which evidence they expect to see for these controls, and treat any vendor claiming a DORA certification as a point to challenge.
How DeployOpen prepares endpoint and data controls and evidence
DeployOpen plans and implements self-hosted open-source platforms that help the financial entity produce evidence for its DORA data and endpoint controls, including configuration baselines, remote wipe and teleworking rules. The organization keeps ownership of its policies and risk decisions, and an independent auditor or supervisor is the party that assesses them.
How we scope
- We agree in writing which endpoints, device types, data stores and teleworking paths fall inside the engagement before work starts.
- We map the agreed scope to the requirements of Article 11 and Article 14 so the organization can see which controls are covered.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and ongoing support is available as a retainer.
How we build
- We configure a secure baseline for in-scope assets and set up verification checks that run on a schedule the organization approves.
- We deploy malware protection, approved software and media controls, and remote management and wipe capability for portable and private devices used for work.
- We set up data loss prevention and secure deletion processes, then test each control against the agreed scope before handover.
How we hand over
- We document baselines, configuration settings, exception handling and the teleworking security requirements in a form the organization can maintain.
- We deliver the evidence the controls produce, such as scan reports, device management records and wipe logs, with notes on how each item is retrieved.
- We confirm with the organization which items are its own policy decisions and which items an independent assessor will need to see.
How we support
- We review baseline drift, scan findings and device compliance reports with the organization's security team on an agreed cadence.
- Upgrades, configuration changes and new device types are handled under a retainer that is scoped and priced separately.
- We help the organization prepare for supervisory or audit questions, while the assessment itself remains with the auditor or competent authority.
