Annex I Part I (2)(l) security logging and monitoring

What Annex I Part I (2)(l) security logging and monitoring asks a product to do

Point (2)(l) asks the manufacturer to build a product that gives security-related information by recording and monitoring its own relevant internal activity. In practice, the product must be able to show who or what accessed data, services or functions, and when those items were modified. The risk this addresses is misuse that goes unnoticed because the product kept no trace, and incident awareness that comes too late because nobody could see the activity that mattered. The manufacturer owns this decision. It is not enough to log everything by default and hope the right events are in the file when an incident occurs.

The difficulty is that logging has to be designed into the product from the start. Authentication events, administrative changes, privilege grants, configuration edits, and access to sensitive data stores all need defined event sources, consistent fields, and protected storage that a normal user cannot quietly alter. The manufacturer's cybersecurity risk assessment decides which events are relevant for each function and where the boundary of logging lies. Confirm with your engineering and product teams which functions handle personal or high-impact data, because those paths usually need the most detailed records and the strongest protection of the log itself.

The opt-out mechanism adds a second design constraint. The user must be able to switch off the recording of certain activity, so the product needs a documented, reachable setting that does not break core functions when it is disabled. Decide early what remains logged even when the user opts out, such as minimal records needed to support a security update or incident response, and how the user is told about the trade-off. Ask for a written test of the opt-out path, not just a toggle in the interface, and keep the result in the technical documentation.

Which product functions, logs and users fall under point (2)(l)

Point (2)(l) does not come with a fixed list of events to log. The manufacturer's Article 13(2) cybersecurity risk assessment decides which activity is security-relevant, which components record it, how long it is kept and how users can opt out. The cards below are the decisions that change the workload most.

Security-relevant internal activity

Start by listing the actions the risk assessment treats as security-relevant: access to data, services or functions, changes to them, privilege grants, failed logins and configuration edits. Each class of action should map to a risk the product faces. Ask the engineering team which functions can alter data or access rights, because those functions define the minimum event set. Record the list and the reason for each item so an assessor can trace it back to the risk assessment.

Components that write logs

Logging usually spans several layers: the application, the operating system, containers, cloud services and the update mechanism. Each layer can record different events, and gaps often appear between them. For example, an application may log a configuration change while the update service logs nothing about who approved it. Inventory every writer, the file or stream it uses and whether its output reaches the same place.

Storage location and retention period

Decide where security logs live, who can read them and how long they are kept. Logs written inside the data directory can be exposed to the same administrators whose actions they record, so integrity and separation matter. Confirm the retention period with the risk assessment and with the customer's own requirements, and check that logs cannot be silently truncated or edited by the account they describe.

Opt-out and the default setting

The requirement pairs logging with an opt-out mechanism for the user. Decide which logging is on by default, which events a user may switch off, and what happens to security-relevant records when the user does so. Document the default, the opt-out path and any event that cannot be disabled without weakening another requirement. Test both states so the documentation matches the shipped behavior.

When the product is a SIEM

If the product collects, correlates or analyzes security events for customers, it may itself belong to an important product class. Annex III point 7 lists security information and event management systems in class I. That classification changes the conformity assessment route, so confirm it during scoping before the logging design is fixed. Products that only emit logs for a SIEM to consume usually stay outside that category, but the boundary should be documented.

How to implement security logging and monitoring in a product

This sequence turns the Annex I Part I point (2)(l) requirement into a working logging chain: the activities that matter are chosen from the risk assessment, recorded in a consistent format, protected, monitored, offered to users with a documented opt-out, and tested end to end. Each step ends with a record that an assessor can examine.

Confirm the security-relevant activity list
Start from the cybersecurity risk assessment and list every internal activity the product must record: authentication events, changes to access rights, reads and writes to sensitive data, changes to services or functions, configuration changes and administrative actions. The product owner and security architect sign off on the list, and each entry names the risk it addresses. The output is the activity list, which becomes the scope for every later step. Keep it in the technical documentation so the reasoning can be traced.
Define the log schema and fields
Set one schema for all security events so that records from different modules can be correlated. Typical fields include timestamp in a single time standard, event type, acting identity, target object, outcome, source address and a product or instance identifier. Decide which values are stored in plain text and which are hashed or omitted, so that the log does not become a second copy of sensitive data. The output is a versioned schema document with a sample record for each event type.
Enable recording at the product layer
Implement event recording inside the product rather than relying only on the host or infrastructure, so that the activity is captured where the access or modification happens. Use the schema from the previous step and make sure failed as well as successful operations are recorded. Where the product relies on a bundled component with its own audit facility, such as an audit log in an open-source application, confirm what it writes, where it writes it and whether the fields meet the schema. The output is a test build in which each listed activity produces a record.
Protect log integrity and access
Restrict who can read, change or delete logs, and separate the logging write path from ordinary administrative accounts. Forward records to a store that the product's users and operators cannot silently alter, and set retention and rotation rules that are written down. Check file permissions, log rotation settings and the storage location in each deployment template. The output is an access matrix for log data and a documented retention setting that the test team can verify.
Add detection rules and alerting
Translate the high-risk entries in the activity list into detection rules, such as repeated failed logins, privilege changes outside an approved window or bulk export of sensitive records. Route matches to the people who must act on them, and record what each alert means and who responds. Where the product integrates with a security information and event management system, which is itself a class I important product category under Annex III, confirm the integration and its ownership. The output is a rule register that links each rule to a risk and a response owner.
Build the user-facing opt-out and its documented effects
Provide a clear, user-controlled way to disable the optional security logging, while keeping the default on for the product's essential security functions. Document what the opt-out stops, which security information the user loses, and any effect on detection or incident reporting. The user must be able to see the current setting. The output is the opt-out design, the user-facing text and the documentation that an assessor can compare against the risk assessment.
Test the whole logging and monitoring chain
Run scripted scenarios that perform each listed activity, then confirm that the record appears in the correct format, reaches the monitoring store, triggers the expected alert and respects the opt-out setting. Include a test where logs are altered or deleted to confirm the integrity controls work, and a test where the opt-out is switched off and on. Record the results with dates, build identifiers and the person who performed the test. The output is the test record, which becomes primary evidence for the conformity file.

How an assessor tests Annex I Part I (2)(l) logging

This table lists the steps a notified body or market surveillance authority takes when it tests the logging and monitoring requirement, with the approach for each step, the evidence it asks for and the findings that most often come up. The assessor runs these tests and records the result, so the manufacturer should read the table as a preparation checklist rather than a self-written verdict.

Test step	Test approach	Evidence requested	Common findings
Scope review against the risk assessment	Check that the risk assessment identifies which internal activities the product records, and why those activities were chosen.	Risk assessment entries for logging, a list of logged activity types, and the design decisions behind them.	Logging scope is asserted but not traced to any identified risk, or the risk assessment is older than the current product version.
Log content review	Confirm each log entry records who acted, what was accessed or changed, when, and from where, for the defined activity types.	Sample log records, log schema or field definitions, and the configuration that controls which events are written.	Entries omit the acting identity or timestamp, or key events such as configuration changes are not logged at all.
Sampling of access and modification events	Select recorded events for access to and modification of data, services and functions, then trace each one back to its source action.	Test accounts and scripted actions with matching log entries, plus the sampling method used by the manufacturer.	Some modification paths, such as administrative APIs or batch jobs, produce no record, so the sample cannot show full coverage.
Integrity and retention checks	Test whether logs can be altered or deleted without trace and whether they are kept for the period the manufacturer has defined.	Access controls on log storage, tamper-evidence mechanisms, retention settings and sample export or rotation records.	Administrators can edit local log files without leaving evidence, or rotation silently discards entries before the stated retention period.
Detection and alert review	Check whether the product or its documented integration detects suspicious patterns and produces alerts that someone can act on.	Detection rules or detector configuration, alert samples, and the process for routing and triaging alerts.	Detection depends on a separate system the customer must deploy, and the documentation does not say so or define the handover.
Opt-out testing	Verify that the user can turn off the recording and monitoring mechanism and that the product behaves as documented afterward.	Documented opt-out procedure, screenshots or test records of the setting, and the stated effect on other security functions.	Opt-out is hard to find, is not documented, or disables logging that other requirements, such as incident reporting, depend on.
Documentation and user information	Review whether the technical documentation and user instructions describe what is logged, where logs go, how long they stay, and how to opt out.	Technical documentation extracts, user manual sections and the version history that matches the tested release.	Documentation describes an earlier release, or it does not match what the product actually records during testing.

Evidence for security logging and monitoring under the CRA

Point (2)(l) is tested through records that show what the product logs, how those logs are used, and how users can opt out. The six artifacts below link the risk assessment to working logs and detections, and each needs a named owner who refreshes it as the product changes through the support period.

Scoped activity list linked to the risk assessment

This is the list of internal activities the product records, such as access to or modification of data, services or functions, traced back to the threats in the Article 13(2) risk assessment. Each entry should name the event source, the reason it is logged, and the point (2) requirement it supports. Review it whenever a feature, interface or data flow changes, and record the review date and the approver. Assessors usually start here, so an activity with no threat behind it invites questions.

Log schema and retention policy

The schema defines the fields every security event carries, such as timestamp, actor, action, target and outcome, and the retention period for each log class. Version the schema so older logs remain readable after a change, and store the retention rule next to the schema. Ask the vendor or your own team to confirm how each platform sets retention and whether logs can be exported before deletion. Gaps here often show up when logs are needed for an incident.

Sample logs for access and modification events

Keep dated samples that show real access and modification events from a test or staging environment, with sensitive values masked. Samples prove the logging works in practice, not only on paper. For Nextcloud, the admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, so capture a sample from that file. Refresh samples after each release that touches authentication or data handling.

Detection rules and alert records

Detection rules turn raw events into findings, and alert records show that someone was notified. Document each rule, its source, its severity and the response owner. OpenSearch Security Analytics matches ingested logs against Sigma rules and records findings, while Wazuh compares events against its built-in and custom rules and writes alerts to alerts.log and alerts.json. Keep alert history long enough to support an Article 14 early warning decision, and confirm how each tool handles alert retention.

Opt-out design and user documentation

Point (2)(l) requires an opt-out mechanism for the user, so keep the design record that shows where the user can disable logging, what is lost when they do, and how the choice is stored and enforced. Pair it with user documentation written in plain language that explains what is recorded and why. Review the design with legal counsel where personal data is involved, because logging of user activity also falls under GDPR. Confirm which settings in each platform can be changed by users and which only by administrators.

Test records for logging and alerting

Test records show that logging, detection and the opt-out work as documented. Keep a repeatable test script that generates a known access event and a known modification event, then checks that the entry appears in the right log, triggers the expected rule and produces an alert. Record the test version, date, result and any defect fixed. Rerun the tests after each release and after any change to the logging configuration, so the evidence stays current across the support period.

How self-hosted open-source tools can produce logging evidence

Nextcloud is licensed under AGPL-3.0-only. Its admin_audit app records additional event information from the server, which gives a product built on Nextcloud a record of administrative and data-related actions. The events are written to a file called audit.log in the data directory by default, or to a different path you set with the logfile_audit configuration key. For point (2)(l), the useful question is whether the events you need, such as access to or modification of files, shares and user settings, appear in that log with enough detail to reconstruct what happened.

Default location: Check whether audit.log sits in the data directory, where it can be backed up with user data, or whether you have redirected it.
Custom path: If you use logfile_audit, confirm file permissions, rotation and that the path is on storage the operator controls.
Event coverage: Test which actions produce entries in your version and configuration, and document any gaps.
Tamper resistance: A plain log file is not tamper evident on its own. Forward copies to a central store that the application cannot edit.
Opt-out handling: If users can opt out of monitoring, document how the setting is enforced and what is still recorded.

Confirm with the vendor and your own testing that the app meets your product's logging scope before relying on it as evidence.

Wazuh is licensed under GPL-2.0-only. It decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques, and forwarded to the Wazuh indexer, where they can be reviewed in the dashboard. Wazuh is useful where you need agent-based collection from hosts and endpoints alongside application logs.

Decoders and rules: Confirm that decoders exist for your product's log formats, and write custom decoders and rules where they do not.
Alert files: Protect alerts.log and alerts.json from modification and include them in your retention plan.
ATT&CK mapping: Use the technique mapping to show which threat behaviors your monitoring addresses.
Indexer forwarding: Check that alerts reach the indexer without loss and that the dashboard history matches the files.
Rule tuning: Document changes to built-in rules, since reviewers will ask why a rule was disabled or modified.

Confirm the ruleset version and coverage for your environment in the Wazuh documentation, and test with events from your own product before you rely on any rule.

What security logging and monitoring costs to meet under the CRA

This table compares the main cost components of meeting Annex I Part I (2)(l) and shows whether each one is paid once or recurs, what pushes it up or down, and what to request in a quote. No price or duration is stated because none has been supplied for this requirement, so treat each row as a list of questions to put to vendors, integrators and your own engineering leads. The main takeaway is that licence spend is often the smallest recurring cost, while storage, rule upkeep and evidence maintenance continue for the whole support period.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Tooling or licenses	Recurring for commercial products, one-time setup for self-hosted	Commercial SIEM licensing often scales with ingested data or endpoints. Self-hosted open source such as Wazuh, OpenSearch Security Analytics or the Nextcloud admin_audit app can remove license spend, but hosting, patching and support remain	Confirm the licence model for each component, the license terms, and whether support is included or sold separately
Engineering time to design logging and the opt-out	One-time, with periodic revision	Number of product functions that touch data, services or privileged functions, and how many user-facing opt-out paths the design must support. Reuse of existing audit configuration reduces effort	Ask for a written list of logged event categories, the opt-out design, and who signs off the design in the technical documentation
Storage and retention infrastructure	Recurring	Event volume, retention period set in the risk assessment, index replication, and backup of audit files such as audit.log or alerts.json. Higher volume and longer retention raise storage and backup cost	Request sizing assumptions for event volume and retention, and a statement of where logs are stored and who can access them
Detection rule tuning	Recurring	Number of enabled rules, the share of noisy alerts, and how many custom rules the product needs. Wazuh ships over 3,000 built-in rules and decoders, so disabling unused rules and writing custom rules both take analyst time	Ask who tunes rules, how often reviews happen, and how false-positive handling is recorded
Evidence upkeep	Recurring for the support period	Frequency of control evidence collection, changes to logged events after each release, and the number of product versions still supported. Each release that changes logged activity needs updated documentation	Ask for the evidence list, collection schedule, and the format in which logs and review records will be delivered to an assessor
External testing or review	Recurring or per engagement	Scope of testing of the logging path, including whether attempts to disable or tamper with logs are tested. Scope and number of products in scope drive effort	Request a fixed scope in writing with deliverables and timing agreed before work begins
Auditor or assessor sampling	Per assessment cycle	Assessor sampling depends on the conformity route and the body chosen. Clear evidence of logged events and opt-out behavior reduces follow-up requests	Confirm with the assessor which evidence samples they will select and whether they need access to live logs or exports

Where logging and monitoring projects usually fall short

Most teams have some logging in place before they start on Annex I Part I (2)(l). The gaps below tend to appear where logs are scoped, protected, tested and maintained, and each one can leave a product with records that look complete but do not support the security information the requirement describes. Work through them against your own risk assessment and the activity list you document for the product.

Access logged, modification missed

Many logs record who signed in or which API was called, but not what changed afterward. Point (2)(l) explicitly covers modification of data, services or functions, so a log that shows access without the resulting change cannot show what happened. Check that every write path to configuration, user records, permissions and stored data produces an event that names the actor, the object and the before and after state where practical. For a self-hosted Nextcloud deployment, for example, confirm that the admin_audit app is enabled and that its output covers the changes you have listed, not only logins.

Logs stored where integrity is not protected

A log that the product or its administrator can silently edit does not provide dependable security information. Decide where each log lives, who can write to it, who can delete from it and whether tampering would be detectable. Forwarding events to a separate collector with restricted write access, and keeping hashes or sealed copies, are common approaches. Test the design by attempting to alter a record as a privileged administrator and confirming that the change is visible. Be careful that logs of sensitive values are handled consistently, as OpenBao, for example, hashes most sensitive values in its audit devices.

Activity list not tied to the risk assessment

Teams often pick logged events from habit rather than from analysis. The list of recorded activity should trace back to the cybersecurity risk assessment required under Article 13(2), which identifies the threats that matter for the product and the activity that would reveal them. Record in the technical documentation which events are captured, why each one matters and which risk it addresses. An assessor reviewing the product will expect that trail, and a gap here usually means the logging scope was never decided, only inherited from the platform defaults.

Opt-out that silently removes security data

Point (2)(l) lets the user opt out of the recording, but an opt-out that switches off all security-relevant events without warning undermines the requirement. Design the setting so that it is explicit, scoped and reversible, and so that the product tells the user what security information will no longer be produced. Avoid tying the opt-out to a general debug or performance option, because users who turn that on for another reason will lose audit records without knowing it. Document the default state and the effect of each option in the user information.

Detection rules never tested on real events

Detection content such as Sigma rules, Wazuh rules or custom correlations often ships untested against the product's own logs. A rule that matches a sample written by the rule author may never fire on the format the product actually produces. Build a set of representative event samples, including normal activity, known misuse and modification events, and run each rule against them before release. Record the results as evidence. Re-run the test whenever the product's log format changes, and confirm that alerts reach a person or system able to act on them.

No review cadence across support period

Logging requirements must hold for the whole support period, which the regulation ties to the product's life. Logs that were complete at release can drift as features, dependencies and interfaces change. Assign an owner, set a review cadence for the activity list, rule set and retention settings, and link each review to changes recorded in the risk assessment. Keep the dated review records, since they show the requirement is being maintained rather than checked once. Where a SIEM is used, treat its own configuration and retention as part of the same review, because SIEM systems are themselves a class I important product category under Annex III.

Who owns logging and monitoring, and what a partner can take on

The manufacturer remains fully responsible for point (2)(l) because the requirement describes how the product behaves, not how a vendor's tooling is configured. The product team and security leadership decide which internal activity is relevant, record that decision in the cybersecurity risk assessment, and define the opt-out mechanism the user can exercise. No implementation partner can make those decisions on the manufacturer's behalf.

Risk assessment and scope: Decide which access to or modification of data, services or functions the product must record, and document why each event type is in or out.
Activity list: Maintain a current list of logged event classes, their fields and retention, and update it when features change.
Opt-out policy: Define what the user can switch off, what the product warns about when logging is disabled, and who approves that wording.
Product behavior: Own the code and configuration that generate the records, including how they are protected from tampering.
Technical documentation: Keep the logging description in the file that supports the conformity assessment.

Before engaging anyone, confirm that the manufacturer can name the owner of each of these items internally.

Questions buyers ask about CRA logging and monitoring

How much effort does CRA logging and monitoring take?

The effort depends mainly on how many security-relevant activities the product performs and how much logging it already has. The work falls into a few parts: listing the internal activity that counts as relevant, including access to or modification of data, services or functions; designing the log content and format; setting retention and protection for the logs; building and testing the user opt-out; and writing the evidence. No researched figure is available for effort, so ask any partner to break the estimate down by these parts in the written scope. Recurring effort continues after launch, including reviewing alerts, tuning detection rules, managing log growth and updating the design when the product changes.

How long does it take to implement CRA logging and monitoring?

No researched duration is available, so confirm any timeline in the written scope rather than relying on a general estimate. The dates that set the outer limits are fixed in the regulation: the Article 14 reporting obligations apply from 11 September 2026, and the regulation applies from 11 December 2027. The main timeline drivers are the number of products and deployment models, whether logging exists today, whether the product is still in design, and how many people must review and approve the design, privacy impact and evidence. Products placed on the market before 11 December 2027 are generally in scope only when substantially modified, but Article 14 reporting applies to in-scope products regardless of when they were placed on the market.

What does our engineering and security team need to provide?

The team's knowledge of the product is the input that cannot be outsourced. Expect to provide:

An architecture view with data flows, external interfaces, admin paths and any third-party services the product calls
A list of security-relevant actions, such as logins, permission changes, data exports and configuration edits, with the owner of each
Access to a test environment where logs can be generated and checked
Decisions on log retention, who may read logs and how long they are kept, agreed with privacy and legal staff
A named person who will review alerts once the product is in service, such as a security operations team or the customer's support staff
Sign-off on the cybersecurity risk assessment that determines which point (2) requirements apply

Can an in-house team meet point (2)(l) without a partner?

Yes, the manufacturer owns its controls and an in-house team can design and implement logging for its own product. The practical question is capacity and skills: logging design, detection engineering, privacy review and evidence preparation are different disciplines, and the team must also keep them running after release. An outside partner can prepare systems and evidence, but it does not issue reports or certificates. Where a product is itself a security information and event management system, Annex III point 7 places it in class I important products, which can change the conformity route, so confirm the classification before deciding who does the work. Independent assessors and notified bodies remain the parties that test conformity where a third-party assessment applies.

What should a partner deliver in a fixed-scope logging engagement?

A fixed-scope engagement should name its deliverables and timelines in writing before work starts. For point (2)(l), reasonable deliverables include a mapping from the product's security-relevant activities to the events it records, a logging configuration for the chosen platform, an implemented and tested opt-out mechanism, detection rules with alert routing, a runbook for reviewing and escalating alerts, and an evidence pack with configuration files, test records and sample log output. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems and evidence for assessments. It does not issue audit reports, attestations or certifications. Ask for the acceptance criteria for each deliverable in the scope document.

How does the opt-out affect our logging evidence?

The opt-out must work in practice, and the evidence has to show it. Keep records of the default logging state, the user-facing control that changes it, what the product records after the user disables logging, and what security-relevant information, if any, is still kept. Test both states and keep the results. Document the privacy basis and the trade-off: fewer logs can reduce the product's ability to detect and assess suspicious events, which matters for the Article 14 early warning of a severe incident within 24 hours of becoming aware of it. Commission guidance C(2026) 5252 discusses how awareness relates to a prompt initial assessment, so confirm your interpretation with your assessor before you rely on it.

Which open-source tools can produce logging evidence for point (2)(l)?

The right tool depends on the product's architecture, and each candidate needs testing against the product's own events. Some examples of what the documentation describes:

Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit.
OpenBao audit devices keep a detailed JSON log of every API request and response, with most sensitive values hashed with HMAC-SHA256.
Wazuh decodes collected logs, compares events against more than 3,000 built-in rules and decoders plus custom rules, and writes alerts to alerts.log and alerts.json.
OpenSearch Security Analytics runs detectors against Sigma rules, records findings and sends alerts to channels such as Slack or email.

Confirm each behavior in your own environment before you cite it as evidence, because logging settings, retention and opt-out handling vary by version and deployment.

How DeployOpen scopes and prepares logging evidence for this requirement

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, including the recording and monitoring of internal activity that point (2)(l) asks for. We prepare the systems, log configuration and evidence, while the manufacturer keeps ownership of its risk assessment, controls and conformity decisions.

How we scope

Written scope lists each product in the logging design, the internal activities recorded, and the access and modification events covered.
The scope records the user opt-out mechanism and where it is configured, so the choice is testable and documented.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure audit logging for access to and changes of data, services and functions, such as the admin audit logs of self-hosted applications.
Where a security monitoring layer is in scope, we set up collection, detection rules and alerting, and test them against sample events.
Log storage location, retention settings and access controls for the logs themselves are configured and checked during build.

How we hand over

Handover documents the logging configuration, the mapping of log sources to recorded events, and the opt-out settings for users.
Test records show that sample access and modification events were captured, stored and reviewed as the design describes.
The manufacturer receives the evidence pack and configuration files, and decides how they feed its risk assessment and technical documentation.

How we support

Ongoing support is available as a retainer for log source changes, detection rule updates and platform upgrades.
Logging configuration is reviewed when the product changes, so the evidence stays aligned with the current release.
Confirm with DeployOpen during scoping which review cadence and support terms apply to your product lifecycle.