What DORA Article 10 detection asks for and why it is hard
A financial entity preparing for DORA supervision has to show that it can spot anomalous activity and ICT incidents quickly, not just that it collects logs. Article 10(1) requires mechanisms that promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents, and that identify potential material single points of failure. Article 10(2) asks for multiple layers of control, alert thresholds and criteria that trigger incident response, and automatic alerts to the staff who run incident response. Article 10(3) requires enough resources and capabilities to monitor user activity, ICT anomalies and incidents, with cyber-attacks named as a priority. Read together, these clauses mean a supervisor will ask who gets woken up, by what rule, and how fast. The detection mechanisms are also not a one-time build: under Article 10(1) they must be tested regularly in line with Article 25, so the entity needs a test plan that exercises the alerts themselves.
The difficulty is that detection depends on evidence spread across many systems. Identity events, API calls, capacity figures, change records, network flows and cloud audit trails usually sit in different tools, with different retention settings and clock sources. Article 12 of Delegated Regulation (EU) 2024/1774 sets the logging expectations behind this, including protection of logs against tampering and deletion, detection of logging failures, and synchronised time from a documented source. A rule that never fires because a log source silently stopped is hard to distinguish from a rule that has nothing to report, so the entity must monitor its own logging pipeline. Practical first steps are to inventory every log source feeding detection, record what each one proves, confirm which single points of failure the detection covers, and agree with the incident response team which alert conditions open an incident. Confirm the exact logging and detection criteria with the current text of the delegated regulation and with your competent authority, since supervisory expectations for evidence may be applied in more detail than the summary here.
Which systems, logs and teams fall under DORA detection scope
Article 10 detection only works if the organization decides what it watches before it buys tooling. The cards below cover the scoping decisions that change the work: the systems and network paths, the user and cloud activity, the proportionality question, and who acts on an alert.
Core ICT systems and network paths
Start with the systems that support critical or important functions and the network paths between them, including links to third-party providers. Article 10(1) asks for detection of anomalous activity and network performance issues, so a sensor that sees only the perimeter misses lateral movement. Record which hosts, segments and gateways feed the detection platform, and check that each one has a named owner and a documented source of logs.
Identity and user activity logs
Access control and identity management events are the most direct evidence of misuse, so they belong in scope from day one. Logging under Article 12 of Delegated Regulation (EU) 2024/1774 covers access control and identity management, and detection rules should flag privileged logins, failed authentication bursts and changes to roles. Confirm which identity provider, directory and application logs reach the platform, and who reviews the alerts they produce.
Self-hosted application audit trails
Self-hosted platforms often keep their own audit records, and those records are only useful if they reach the central detection store. Nextcloud's admin_audit app writes to audit.log in the data directory unless a path is set with logfile_audit, and OpenBao audit devices record every API request and response. Confirm that each application's audit file is forwarded, that the path is protected from tampering, and that log failures raise an alert.
Cloud and managed service telemetry
Cloud control planes, managed databases and container platforms generate activity that sits outside the hosts you operate. Ask which control plane events, storage access logs and network flow records the provider exposes, and whether your contract lets you export them to your own store. Where a third party runs a function for you, detection responsibility still sits with the financial entity, so confirm the export path and retention in the contract.
Proportionality and detection depth
Article 4 scales DORA to the size, risk profile and complexity of the entity, so depth should follow the criticality of each system rather than a single uniform rule. A small entity may start with identity, perimeter and core application logs and add correlation later, while a larger one may run correlation across many sources. Document the reasoning for each tier, because supervisors will ask how the depth was chosen and whether it was applied reasonably.
Alert ownership and escalation
Article 10(2) requires automatic alerts to the staff in charge of incident response, so each alert class needs a named owner and an escalation path. Define who triages, who declares an ICT-related incident and who is on call outside working hours. Test the path with a sample alert before go-live, and record the owner on each detection rule so the alert does not stop at a shared mailbox.
How supervisors test detection controls
The first pass is a paper review. The supervisor reads the detection policy, the procedures behind it and the threshold definitions, then checks that they cover anomalous activity, network performance issues and ICT-related incidents as Article 10(1) requires. The reviewer looks for a clear link between each detection mechanism and the criteria that trigger incident response, because Article 10(2) requires alert thresholds and criteria to be defined, not left to operator judgment.
- Detection policy scope: Confirm that the policy names the systems, log sources and user activity it covers, and states which layers of control exist.
- Threshold register: Ask for a list of alert thresholds with the rationale, owner and review date for each.
- Trigger criteria: Check that each criterion maps to a defined incident response step under the incident management process.
- Logging requirements: Compare the policy against the logging scope set in Article 12 of Delegated Regulation (EU) 2024/1774, including clock synchronisation and protection of logs.
- Alert ownership: Look for a named role or team for every alert class.
A common finding is a threshold that exists in a document but has no owner or review record. Before an inspection, confirm that every threshold can be traced to a rule, a responsible person and a review entry.
The second pass checks whether detection works as documented. A supervisor, or the firm's own assessor on their behalf, selects a sample of log sources and asks staff to show the path from event to alert: where the log is collected, how it is decoded, which rule matches it, where the alert lands and who receives it. The goal is to confirm that alerts reach staff in charge of incident response automatically, as Article 10(2) expects, and that multiple layers of control overlap rather than depend on a single tool.
- Live detectors: Ask for a live view of the rule set, its last update and the log types each rule reads.
- Alert routing: Trace one alert to a notification channel and an acknowledgement record. Confirm that the route still works after a change in staff.
- Layered coverage: Show two independent detections for a sample scenario, such as a failed privileged login, to test that the layers overlap.
- Log tamper protection: Demonstrate that log stores restrict deletion and that gaps in logging are themselves detected.
- Clock source: Show the documented time source and the synchronisation status of the sampled hosts.
A frequent finding is an alert that fires into a shared mailbox or chat channel nobody watches. Run a sample alert during the walkthrough and time how long it takes to reach a person who can act on it.
The third pass asks whether detection has been exercised, not just installed. Article 10(1) requires detection mechanisms to be regularly tested in accordance with Article 25, which places them within the firm's wider testing programme. The supervisor looks for a test plan, a record of test scenarios, the results and the remediation that followed. A detector that has never fired in a test is either well tuned or never tested, and the evidence should show which.
- Test plan: Ask for the schedule and the scenarios covered, including simulated anomalous activity and log source failures.
- Test results: Look for records showing whether each scenario produced an alert, at what time and to whom.
- Missed detections: Review each test that failed to alert, the root cause and the tuning change or fix.
- Independence: Check who designed and reviewed the tests, and whether the testers were separate from the people who operate the detectors.
- Lessons carried forward: Confirm that test findings feed back into the threshold register and the risk assessment.
A common finding is a test programme that runs the same benign scenario each year, which proves little. Ask the team to show a scenario added in the last cycle and the detection it prompted.
How to build detection that meets Article 10
The sequence turns Article 10 from a requirement into a working detection capability: defined criteria, centralized logs, tuned alerts, layered controls, tested detectors and a documented record of each step that an assessor can follow.
Define anomaly and incident criteria
The security lead and the ICT risk function write down what counts as anomalous activity, network performance degradation and an ICT-related incident for your environment, using the criteria in Article 23 of Delegated Regulation (EU) 2024/1774 as the baseline. Cover user activity, privileged actions, service availability and known attack patterns for each critical or important function. The step is done when the criteria are approved by the management body or its delegate and mapped to the business functions identified under Article 8. Record the approved criteria as a versioned document with an owner and review date.
Centralize logs under Article 12 criteria
The platform team connects identity, access control, capacity, change, ICT operations and network traffic sources to one log pipeline, as Article 12 of Delegated Regulation (EU) 2024/1774 requires. Protect the logs against tampering and deletion, configure clock synchronization to a documented reliable time source, and alert on logging failures themselves. Application audit trails for self-hosted platforms, such as the admin audit log in Nextcloud or the request audit device in OpenBao, should be forwarded into the same pipeline. The step is done when a sample event from each source can be found in the central store with a verified timestamp.
Build detection rules and decoders
The security engineers load prepackaged rules and decoders, then write custom rules for the criteria defined in the first step. Tools such as Wazuh, with its built-in ruleset plus custom rules, or OpenSearch Security Analytics, which matches logs against Sigma rules, can serve as the detection layer. Map each rule to the criterion it implements so every detection has a traceable reason to exist. The step is done when each approved criterion has at least one rule or confirmed exception, and the mapping is stored with the detection documentation.
Set alert thresholds and automatic routing
The incident response lead sets alert thresholds, severity levels and the triggers that open an ICT-related incident, then configures automatic alerts to the staff on call through channels such as email, chat or the ticketing system, as Article 10(2) requires. Confirm each alert path with a test message and document who receives which severity out of hours. Watch for alert fatigue, because a threshold set too low buries real incidents. The step is done when a test alert reaches the named responders within the routing rules and the thresholds are signed off.
Add layered controls across the stack
The architecture owner adds detection at more than one layer, so a failed control at one level does not blind the organization. Typical layers include host and endpoint events, application audit logs, network traffic analysis, cloud service logs and correlation across them. OpenSearch correlation graphs or equivalent cross-source linking can connect findings that look minor on their own. Map the layers to the material single points of failure identified under Article 10(1), and check that each critical system has detection at least at two layers. The step is done when the layer map is documented and reviewed against the asset inventory.
Test detectors on a regular schedule
The security testing team runs simulated or replayed events against each detector to confirm it fires, routes correctly and produces the expected finding. Article 10(1) requires regular testing of all detection mechanisms in line with Article 25, so define the cadence and scope in the testing programme. Testing may be performed by internal staff or an external provider, and results should cover failed detections as well as successes. The step is done when each detector has a recorded test with date, method, tester and outcome, and gaps have tickets with owners.
Record evidence and review each step
The compliance lead collects the outputs of every previous step into one evidence pack: approved criteria, log source inventory, rule mapping, alert routing tests, layer map and detector test records. The pack is reviewed by the ICT risk control function, and findings feed back into the criteria and thresholds as the environment changes. Ask your independent assessor early which format they expect. The step is done when the evidence pack is current, has a named owner and shows at least one completed review cycle.
Evidence that shows detection works between audits
Article 10 detection is judged on whether the criteria, rules, alerts and tests still match the environment on the day a supervisor asks. The cards below are the artifacts an assessor is most likely to sample, and each one needs a named owner and a review cycle so it stays current between audits.
Detection policy and criteria
A dated document that defines what counts as an anomalous activity, which events trigger ICT-related incident response, and who is paged. Supervisors compare it against the alert thresholds actually configured, so every criterion in the policy should point to a rule or detector ID. Review it at least yearly and after any major incident, and record the approver. Confirm with your own ICT risk management team how the criteria map to the Article 23 requirements of Delegated Regulation (EU) 2024/1774.
Log source inventory
A current list of every system feeding the detection pipeline, including identity providers, hypervisors, network devices, cloud control planes and business applications. For each source, record the log type, retention location, owner and whether logging is enabled. Gaps in this inventory are a common finding, because a detector cannot alert on a source it never receives. Reconcile it against the asset inventory required under Article 8 at each review.
Rule and threshold records
Version-controlled records of every detection rule and alert threshold, with the change history showing who altered each one, when, and why. In OpenSearch Security Analytics, detectors match logs against Sigma rules, and in Wazuh, decisions rest on built-in and custom rules. Keep exported rule sets, the tuning rationale and any suppressed rules with an expiry date. An assessor will ask why a threshold has the value it has.
Alert samples and responses
Real alert records with timestamps, the triggering rule, the affected asset and the response ticket. Pull a sample across severities and across the reporting period, not only the easiest cases. Each alert should show time of detection, time of triage and the decision taken, so the chain from anomaly to response can be traced. Wazuh writes alerts to alerts.log and alerts.json, which gives a stable source for these extracts.
Article 25 detector test results
Records from the regular tests that prove each detection mechanism still fires. Use planned exercises that inject known malicious or anomalous events, then log whether the expected alert was raised, how long it took and what was missed. Failed tests should lead to documented fixes and a retest. Agree the test scope and frequency in advance, and keep the test plan alongside the results so the cadence is visible to a supervisor.
Logging failure reports
Periodic reports showing that log collection itself is working, including silent sources, dropped events, full disks, expired certificates and clock drift. Article 12 of Delegated Regulation (EU) 2024/1774 expects logging failures to be detected, and the reports prove it. Record each failure, its duration and the remediation. Clock synchronization to a documented time source should appear in these reports as well, since mismatched timestamps weaken every other piece of evidence.
What meeting Article 10 detection costs in money and effort
This table breaks the cost of Article 10 detection into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to scope a quote and to see which parts an internal team can absorb and which an implementation partner or tester would usually carry. No fixed figures are given because none were supplied for this topic.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Log platform licenses or self-hosting effort | Software vendor for licenses, or internal staff and infrastructure team if self-hosted | Licenses recur. Self-hosting setup is one-time, then recurs as operations | Volume of events ingested, number of hosts and cloud services, and whether support contracts are needed |
| Engineering time to onboard log sources | Internal platform or security engineers, or an implementation partner under a written scope | One-time per source, plus recurring when systems change | Number and variety of sources, legacy systems, and how many sources already forward logs |
| Writing and tuning detection rules | Internal detection engineers or a partner, with analyst input on false positives | One-time for the initial set, then recurring for tuning and new threats | Number of use cases, alert thresholds defined under Article 10(2), and how mature the existing ruleset is |
| Log storage and retention | Infrastructure team or cloud provider for storage, and legal or compliance owners for retention periods | Recurring, growing with retention length and volume | Retention periods set by the entity's own policy, compression, tiering and log volume |
| Logging integrity and time synchronization | Internal infrastructure team, sometimes with tooling costs | One-time setup, then recurring checks | Number of logging systems that need protected storage and a documented time source under the ICT risk management RTS |
| Detection testing under Article 25 | Internal red or purple team, or an external tester engaged under a written scope | Recurring, usually on a set schedule and after major changes | Number of detection mechanisms, scenarios tested, and whether results must be reproduced for supervisors |
| External review or independent assessment | External reviewer or consultant. Only an independent auditor issues reports | Typically recurring at the review cycle, sometimes one-time for an initial gap review | Scope of detection controls reviewed and whether the entity wants a gap analysis before supervisory inspection |
| Staff for monitoring and alert response | Internal security operations staff, or a managed service provider contracted by the entity | Recurring, the largest ongoing item for most organizations | Hours of monitoring coverage, alert volume, and the staffing model the entity chooses |
Who owns detection, who builds it, and who assesses it
The financial entity remains accountable for detection under Article 10. Its management body approves the ICT risk framework, its security and operations staff decide which anomalies matter to the business, and its incident response staff act on alerts. No partner can take over that accountability, so the in-house team must be able to explain every alert threshold and why it was set.
- Ownership of thresholds: Staff define the alert thresholds and trigger criteria that start incident response, and they document the reason for each one.
- Alert response: Named responders receive automatic alerts, triage them, and record the outcome.
- Log and source decisions: The team decides which systems, identities and network paths must produce logs, and who reviews them.
- Regular testing: Internal staff schedule and review tests of detection mechanisms, as Article 10(1) requires them to be tested.
- Management reporting: The team supplies the metrics and incident trends that the management body reviews.
Check that each detection rule has a named owner, a documented threshold and a record of its last test.
An implementation partner such as DeployOpen plans, builds and configures the detection stack inside the client's own infrastructure, then prepares the evidence that shows how it works. The partner does not own the controls and does not decide what the entity considers material. Its work is bounded by a written scope agreed before work starts.
- Build and configuration: The partner deploys self-hosted log collection, correlation and alerting components, and connects them to the entity's systems.
- Detection testing: The partner runs scheduled checks that confirm alerts fire for defined test events, and reports the results to the client.
- Evidence preparation: The partner packages configurations, rule sets, test records and sample alerts so the client can present them.
- Hardening and upgrades: The partner maintains the detection platform under the agreed support arrangement.
- Knowledge transfer: The partner documents the system so the in-house team can operate it after handover.
Confirm in the statement of work which parts are one-time build work and which are recurring support, and who holds administrative access to the logs.
Independent auditors, assessors and competent authorities reach conclusions about whether detection meets Article 10 and the detection criteria in Article 23 of Delegated Regulation (EU) 2024/1774. DORA sets no certification scheme for this, so no partner or consultant can issue a compliance certificate for detection. Supervisors use their powers under Article 50 to examine the entity's records directly.
- Independence: Assessors must not design or operate the controls they test, which is why the partner prepares evidence rather than judging it.
- Sampling and walkthroughs: Assessors select alerts and events, trace them through the system, and ask staff to explain their decisions.
- Log integrity checks: Assessors look at whether logs are protected from tampering and whether logging failures are detected, as the RTS requires.
- Findings and conclusions: Only the assessor issues the findings, and the entity decides how to respond to them.
- Supervisory examination: A competent authority may request the same records during supervision.
Ask any firm you engage to state in writing what it will and will not sign, and whether it is independent of the build work.
Where detection programs usually fall short
Most detection programs fail in predictable places: the logs that matter never reach the monitoring platform, the alerts reach nobody accountable, and the thresholds and rules are never checked again. Article 10 treats each of these as a detection failure, so assessors look for evidence that every link in the chain works and has been tested.
Log sources missing from detection
A detection mechanism can only flag what it ingests. Identity providers, cloud control planes, VPN gateways, database audit trails and network devices are often left out because they belong to different teams. Build an inventory of log sources tied to critical functions and compare it against what the detection platform actually receives. Ask who owns each feed and how a silent feed would be noticed.
Alerts without named responders
Article 10(2) requires automatic alerts to the staff in charge of incident response, so an alert routed to a shared mailbox nobody reads does not satisfy the requirement. Check that every alert channel, such as email or chat, maps to named roles, out-of-hours cover and an escalation path. Test the route end to end with a sample alert and record who acknowledged it.
Thresholds never reviewed
Alert thresholds and detection criteria set at deployment often drift away from real activity as systems, users and attack patterns change. Thresholds that were never reviewed produce either floods of noise that teams learn to ignore or silence that hides real anomalies. Record each threshold with its rationale, owner and review date, and check whether false positives and missed events were analysed at the last review.
Logs that can be altered
Article 12 of Delegated Regulation (EU) 2024/1774 requires that logs be protected against tampering and deletion, and detection is only as credible as the records behind it. Logs stored on the same host as the monitored system, or writable by administrators, can be erased after an intrusion. Confirm that logs are forwarded to a separate store with restricted write access, and that deletion or gaps in logging are themselves detected.
Unsynchronized clocks
Event correlation across identity, network and application logs fails when timestamps disagree. Article 12 of Delegated Regulation (EU) 2024/1774 calls for clock synchronisation to a documented reliable time source. Verify that every monitored host, device and cloud service uses that source, and that the time source and any drift are themselves logged and monitored.
Detection never tested
Article 10(1) requires all detection mechanisms to be regularly tested in accordance with Article 25. Many programs assume a rule works because it was once deployed, yet a parser change or a retired log source can quietly disable it. Schedule test cases that generate known malicious and anomalous events, confirm that each one produces a finding and an alert, and keep the results as evidence.
Common questions about DORA Article 10 detection
How much does DORA Article 10 detection cost to put in place?
No supplied source gives a price for this work, and DeployOpen does not publish a price list, so a quote follows from the written scope. The main cost components are staff time for the log source inventory and detection engineering, the infrastructure that runs the log platform inside your own cloud or data center, any commercial licences for the parts you choose, testing of the detections, and ongoing tuning and analyst time. Some open-source software carries no licence fee, but the operation around it still costs money. Setup is mostly one-time work, while hosting, tuning, testing and alert handling recur. Costs rise with the number of in-scope systems, log volume, retention periods and whether you run an in-house security operations function. Ask any provider for an itemized quote that separates one-time build work from recurring support, names who performs each task, and states what you must supply.
How long does it take to get detection controls in place?
No supplied source gives a duration, so the schedule depends on the agreed scope and your starting point. DORA has applied since 17 January 2025, so if your detection capability is not yet in place, the obligation is already live and planning should start now. The elapsed time usually depends on how quickly you can produce an asset inventory and a list of log sources, how many systems need onboarding, whether network and cloud sources need new access, and how fast your teams approve alert thresholds and response contacts. Testing of the detections under Article 25 adds time at the end. Ask for a milestone plan with dependencies on your side, so that delays in approvals or access are visible before work starts.
How much work do our own staff need to contribute?
Your organization owns its controls, so internal staff must make decisions that an implementation partner cannot make for you. Typically this includes naming owners for each log source, confirming which systems support critical or important functions, approving alert thresholds and the criteria that trigger incident response, and providing named responders who receive automatic alerts as Article 10(2) requires. Your team also needs to review detections for false positives and act on alerts. Staff time is needed throughout the build, not only at the start. Before agreeing on scope, ask which tasks the provider will perform, which fall to you, and how many hours of your people's time the plan assumes, so that the engagement does not stall waiting for decisions.
Can a small team run DORA detection on its own?
A small team can run detection if its scope is well defined, and DORA's proportionality principle in Article 4 allows requirements to scale with an entity's size, risk profile and complexity. In practice, a small team should start with its critical or important functions, use prepackaged detection rules where they fit, document alert thresholds and response paths, and keep a clear record of tests. The hard part is sustained operation: someone must watch alerts, tune rules, investigate anomalies and keep log sources healthy over time. If your team lacks that capacity, consider a fixed-scope engagement to build the detection layer and document it, followed by a retainer for upgrades and continuous support if you want that help after handover. Confirm with your competent authority how proportionality applies to your entity.
Are open-source tools like Wazuh and OpenSearch acceptable evidence for DORA?
DORA does not certify tools, so no open-source platform is accepted or rejected as a product. What counts is evidence that your detection controls work as designed. Tools such as Wazuh, which compares collected events against a ruleset of over 3,000 built-in rules and decoders and writes matches to alerts.log and alerts.json, can produce that evidence. OpenSearch Security Analytics can record detector matches as findings and send alerts, while OpenBao audit devices keep detailed request logs. Evidence to retain includes the rule configuration, alert thresholds, sample alerts and their handling records, log source inventories and results of detection tests. Your competent authority judges whether the overall control meets the requirements. Confirm each platform's current capabilities with its documentation before you depend on them.
What do the logging and detection criteria in the RTS require from our tools?
Article 23 of Delegated Regulation (EU) 2024/1774 specifies the detection of anomalous activities and the criteria that trigger incident detection and response, implementing Article 10(1) and (2). Article 12 of the same regulation requires logging of events on access control and identity management, capacity management, change management, ICT operations and network traffic. Logs must be protected against tampering and deletion, logging failures must be detected, and clocks must be synchronized to a documented reliable time source. For engineers, this means shipping logs off the source host, restricting who can alter or delete them, monitoring for sources that go silent, and recording the time source configuration. Check each requirement against the regulation text itself, since this summary does not replace it.
Who verifies that our DORA detection works, and does DeployOpen certify it?
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Competent authorities supervise DORA compliance, and DORA sets no certification scheme for detection controls. The only authority-issued attestation the Regulation provides for concerns whether a threat-led penetration test met its requirements. Within your own organization, Article 10 requires regular testing of detection mechanisms under Article 25, and your internal audit function and any independent assessor you engage can review the results. Ask any provider to state in writing what it delivers, what it does not deliver, and who signs off the evidence pack.
How DeployOpen prepares detection evidence for DORA
DeployOpen's work on Article 10 starts with scoping the detection estate, because a detection mechanism can only be shown to be prompt and layered if the organization knows which systems, user populations and ICT services it covers. We map the log sources for identity and access, capacity, change management, ICT operations and network traffic, and we identify where a single point of failure could hide an anomaly. The organization owns the scope decision and the resulting risk assessment. Once the scope is agreed in writing, we deploy the detection tooling inside the client's own cloud accounts, data centers or air-gapped networks, using self-hosted open-source platforms such as Wazuh, OpenSearch Security Analytics and OpenBao audit devices. We do not operate the client's detection on our side of the network, and we do not issue audit reports or attestations. Independent auditors and competent authorities assess compliance and issue any findings. Engagements are fixed-scope, and the scope, deliverables and timelines are set out in a written quote before work begins.
Once the sources are flowing, we configure the controls that Article 10(2) asks for: multiple layers of detection, alert thresholds, and automatic alerts routed to the staff who run incident response. In practice this means confirming which Wazuh rules and decoders apply to each source, writing custom rules where the built-in ruleset does not fit, and defining the OpenSearch detectors and Sigma rules that produce findings and alerts. We also check that logging meets the criteria in Article 12 of Delegated Regulation (EU) 2024/1774, including protection of logs against tampering and deletion, detection of logging failures, and clock synchronization to a documented time source. Each of these settings should be recorded so a reviewer can trace it. Ask any implementation partner to show the change record for each rule and threshold.
Under Article 10(1), all detection mechanisms must be regularly tested, so we run controlled test cases against the detectors and record whether each alert fired, reached the right channel and produced a finding with the expected severity. The evidence we prepare includes the scope register, configuration baselines, rule and threshold records, test results with timestamps, and a log of detector failures and the corrective action taken. Organizations should confirm with their own compliance lead how often these tests must run and how they link to the testing programme under Chapter IV, because the cadence is their decision and the auditor's to judge. Decide early who owns alert triage and who approves threshold changes, since those roles are what an assessor will ask about first.
