IR 2024/2690 3.2 monitoring and logging: evidence

What IR 2024/2690 3.2 monitoring and logging requires

Point 3.2 of the Annex to Implementing Regulation (EU) 2024/2690 asks the entity to run procedures and tools that monitor and log activity on its network and information systems, so that events which could be incidents are detected, with monitoring automated where feasible. In practice that means four linked duties: collect the right activity records, review them and act on alarm thresholds with a qualified response, protect and retain the logs, and keep time sources synchronized while the logging itself stays redundant and independently watched. The regulation binds digital infrastructure and digital provider entities such as DNS, cloud, data center, CDN and managed service providers, and reaches them through the national laws that transpose NIS2. It sets no fixed retention period, so the compliance lead must define one and be able to justify it to a supervisor.

The requirement is hard for three recurring reasons. First, logs are noisy: when every host, identity and network device writes everything at full volume, real signals are buried, so the team needs an explicit list of which elements point 3.2.3 requires (network traffic, permission changes, privileged activity, access to critical configuration and backup files, and so on) and a deliberate decision on what is logged where. Second, alarms often have no owner: a threshold that fires into a shared mailbox produces no timely, qualified response. Assign each alarm class to a named role and record the response. Third, logs are often stored where administrators can change them, which defeats the protection duty. Confirm that log destinations are write-restricted, separated from the systems they describe, and that access to them is itself logged.

To check readiness, ask three questions of your own environment: can you show a log sample containing each point 3.2.3 element for a sample system, can you show configured thresholds and the record of past alarms and responses, and can you show that your logging platform would still raise an alert if the systems it watches went silent. ENISA's June 2025 technical guidance lists SIEM systems, EDR or XDR tools, log samples, configured alarm thresholds and records of past alarms as examples of evidence, which gives a useful checklist. Confirm with your national competent authority or your legal adviser how it reads retention and review frequency for your sector, since the regulation leaves those choices to the entity.

Which systems and log sources IR 2024/2690 3.2 applies to

Point 3.2 applies to the network and information systems in scope for the entity's Article 21 program, not only to the systems that feel critical. The decisions below determine which systems, log families and outsourced services the monitoring work must cover.

Systems in the risk assessment scope

Start from the network and information systems that the entity's risk assessment places within its NIS2 scope, including the services and assets those systems depend on. Each in-scope system needs a defined log source, an owner and a review route. Systems left out of scope should be recorded with the reason, so an assessor can see the boundary was a deliberate decision. Check that the asset inventory matches this list, because a system that is not inventoried is easy to leave unlogged.

Network traffic and boundary devices

Point 3.2.3 expects network traffic to be logged where appropriate, which usually means firewalls, VPN concentrators, load balancers, and the links between segments. The decision is which points give enough visibility to detect events that could be incidents, not every switch port. Confirm that segmentation boundaries are covered, because lateral movement often appears there first. Record the sampling or retention approach for high-volume flows.

Identity, privileged and admin activity

Authentication events, user creation, permission changes and privileged sessions are named in point 3.2.3 and tend to carry the highest-value detections. Include directory services, single sign-on, privileged access tools and the administrative consoles of each platform. Decide who reviews privileged activity and how quickly, since an unreviewed admin log gives no protection. Confirm that service accounts are covered as well as human accounts.

Applications and security tool logs

Application access logs and the logs of security tools such as endpoint detection, vulnerability scanners and the monitoring platform itself fall within the point 3.2.3 list. Self-hosted applications need their audit features switched on and their log paths directed to the central pipeline. Security tools should log their own configuration changes, so a disabled sensor does not go unnoticed. Check that the monitoring stack is itself monitored for availability, as point 3.2.6 requires.

Backups and critical configuration

Access to critical configuration files and backup sets is a specific point 3.2.3 element, and backup stores are a common target for attackers who want to remove recovery options. Log reads, writes and deletions on backup repositories and configuration management stores, and alert on changes outside approved windows. Coordinate this with the backup and configuration controls so the same systems are not defined differently in each place. Confirm which backup copies are off-network, since those need logging too.

Resource use, physical and environmental events

Point 3.2.3 lists resource use, physical access and environmental events where appropriate. For a self-hosted platform this can mean capacity metrics on critical hosts, badge or door events for server rooms, and alarms from power, cooling or fire systems. These sources matter most where they can indicate an attack, such as unexpected resource spikes from cryptomining or access outside working hours. Decide which signals feed the same review queue, and which stay with facilities teams.

Third-party and managed service logs

Cloud platforms, managed security providers and hosted SaaS tools often produce logs the entity cannot see by default. Contract terms should state which log families the provider supplies, how long it keeps them, and how the entity receives them in near real time. The entity still owns the review, alarm thresholds and response for these logs, so unreceived provider logs count as a gap. Confirm the export format and whether events arrive with usable timestamps.

Which events the logs must capture under point 3.2.3

Point 3.2.3 asks that logs cover a list of event categories where appropriate: network traffic, user creation and permission changes, system and application access, authentication events, privileged activity, access to critical configuration and backup files, security tool logs, resource use, physical access and environmental events. The practical starting point is therefore a log source inventory that maps each system in scope to the categories it can produce, not a tool selection. Start from the asset inventory and the risk assessment, then list for each system what it generates, who owns it, where the records go and how long they stay available. A SIEM or log platform cannot capture an event class that no source emits, so gaps found at this stage are cheaper to close than gaps found by an assessor.

Some categories are missed more often than others. Privileged activity is frequently logged for interactive logins but not for changes made through automation, service accounts, hypervisor consoles or database administration tools. Access to backup files and critical configuration is often absent because backup repositories and configuration stores sit outside the application team's view. Security tool logs are the most overlooked: the EDR console, the firewall management plane and the SIEM itself generate records about their own health and changes, and those records are needed to show that detection was not switched off. Ask each system owner to confirm, with a sample export, that these categories appear in practice and not only in a vendor data sheet.

The phrase "where appropriate" is a decision the entity makes and must be able to defend. A reasonable record shows the category, the systems it was excluded from, the risk reason and the approver, and it is revisited when the architecture changes. Excluding physical access logs for a cloud-only workload may be defensible, while excluding them for a data center hosting the same workload may not. Expect a supervisor to test the reasoning as well as the output. Confirm the exact evidence expectations with your competent authority and the ENISA technical guidance of June 2025, which lists log samples containing the point 3.2.3 elements as examples of evidence.

How an assessor tests monitoring and logging

This table sets out the question an assessor asks for each sub-point of point 3.2, the evidence they request, and the findings that commonly appear. Read each row as a test: the question is what the assessor needs to be satisfied, and the evidence column shows what to have ready before the review starts. The main takeaway is that thresholds, alarm responses and log protection must be documented and demonstrable, not just configured.

Sub-point	Question the assessor asks	Evidence requested	Common findings
3.2.3 Log coverage	Do logs capture the event types listed for the systems in scope, where appropriate?	Log source inventory, sample log extracts showing network traffic, account changes, authentication, privileged activity, backup file access and security tool events	Authentication or privileged activity not logged; backup and configuration file access absent; no mapping from log types to in-scope systems
3.2.3 Log content	Do sampled entries contain enough detail to identify who did what, where and when?	Redacted sample entries with timestamps, user or service identity, source and outcome	Entries lacking user identity or timestamps; logs written locally with no central collection
3.2.4 Thresholds	Are alarm thresholds defined, documented and tied to the unusual trends the logs are reviewed for?	Written threshold register, rule configurations, and the rationale for each threshold	Thresholds set at tool defaults with no documented rationale; no thresholds for privileged or authentication events
3.2.4 Review and alarms	Are logs reviewed regularly and do alarms trigger automatically where appropriate?	Review schedule or records, alert configuration, notification routing	Reviews described but not recorded; alerts sent to a mailbox nobody monitors
3.2.4 Response	Does each alarm receive a timely, qualified response, and can the response be traced?	Ticket or case records for sampled alarms with triage notes, escalation and closure reasons	Alarms with no recorded response; closures without reasons; response roles unclear
3.2.5 Retention	Are logs kept and backed up for a predefined period that the organization has set and can justify?	Documented retention period by log type, backup job records, restore evidence for sampled logs	No documented period; retention set by storage limits; backups not tested
3.2.5 Protection	Are logs protected from unauthorized access, deletion and modification?	Access control lists for log stores, integrity controls such as hashing or write-once storage, records of who can administer the log platform	Administrators can edit or purge logs without oversight; no integrity protection; shared credentials on the log platform
3.2.6 Time synchronization	Do systems in scope use synchronized time sources, to the extent feasible?	Time source configuration for sampled hosts, drift monitoring output, documented exceptions	Hosts drifting from different time sources; logs with inconsistent timestamps used in incident timelines
3.2.6 Redundancy	Are monitoring and logging systems redundant so that a single failure does not blind the organization?	Architecture diagram of logging components, failover tests, capacity records	Single collector or indexer with no failover; logging disabled silently when storage fills
3.2.6 Independent availability	Is the availability of monitoring and logging watched separately from the systems being monitored?	Health check configuration, alerts for missing log sources, records of outages and response	No alert when a log source stops sending; availability checked only by the monitored platform itself

How to implement point 3.2 step by step

This sequence turns point 3.2 of the Annex to Implementing Regulation 2024/2690 into a working monitoring and logging chain, where each step produces an artifact an assessor can trace from log source to alarm response to tested outcome.

Build the log source inventory from the asset inventory
Start from the asset inventory maintained under point 12.4, and list every system, application, network device, cloud service, security tool and backup platform that produces logs or holds critical configuration and backup files. The asset owner confirms each entry, and the security team records where each source sends its logs and who can change that setting. The step is done when every in-scope asset has either a logging source or a documented reason it has none. This inventory is the first evidence artifact, because it shows the assessor that coverage starts from a known asset base rather than from whatever tools happen to be installed.
Decide event coverage for each log source
For each source, decide which of the point 3.2.3 event types apply, such as network traffic, user creation and permission changes, authentication, privileged activity, access to critical configuration and backup files, security tool logs, resource use, physical access and environmental events. The regulation applies these where appropriate, so the decision and its rationale should be written down per source, approved by the system owner, and reviewed when the asset changes. The output is a coverage matrix that maps sources to event types. Assessors often test this matrix against a sample of logs, so the matrix should match what is actually collected.
Configure collection and detection rules with alarm thresholds
Configure collection so events reach a central analysis point, then write detection rules and alarm thresholds that fire on unusual trends and on events that could be incidents. Platforms such as Wazuh, OpenSearch Security Analytics with Sigma rules, or a SIEM can support this, but the platform choice should follow the coverage matrix and not the reverse. Document each threshold with its rationale, its owner, and whether the alarm triggers automatically. Point 3.2.4 expects alarms to trigger automatically where appropriate, so record which thresholds do and which are reviewed by a person. The output is a rule register and a threshold register that can be exported for an assessor.
Define the alarm response procedure and named owners
Write a response procedure that states who triages each alarm class, how fast triage must happen as defined in the organization's own policy, when an alarm escalates to incident handling, and who can close it. Each role needs a named person and a deputy, and the procedure should cover after-hours coverage. Point 3.2.4 requires a timely, qualified response, so the procedure should show how qualification is achieved through training and records. The output is a signed procedure and a roster. Keep the ticket records of past alarms, because ENISA's June 2025 guidance lists records of past alarms as evidence.
Design retention, protection and access control for logs and backups
Set a predefined retention period for each log class, a backup schedule for log stores, and access rules that restrict who can read, modify or delete logs. The regulation sets no fixed retention period, so the period must come from the organization's risk assessment and its legal obligations, and the reader should confirm it with legal counsel and any sector regulator. Protect logs from unauthorized change through separate administration, write-once or integrity controls where the platform supports them, and separate accounts for log administrators. The output is a retention schedule and an access matrix that an assessor can test by attempting a modification with a non-authorized account.
Synchronize time and make logging redundant
Point all systems to synchronized time sources where feasible, and record the source, the stratum or equivalent configuration, and the systems that were excluded with reasons. Build redundancy into the monitoring and logging systems so that a single failure does not silence detection, and monitor the availability of these systems through a path independent of the systems they watch. Independent availability monitoring might alert a different team or use a separate host, and the design should show this. The output is a time configuration record, a redundancy diagram, and an availability alert with test records showing it fires when the logging service stops.
Test the full chain and keep the results
Run an end-to-end test that generates a controlled security event on a sample of sources, then confirms the event is collected, matched by a rule, alarmed at the documented threshold, triaged by the named owner, and recorded with a timestamp consistent with synchronized time. Repeat the test after a logging component fails to confirm the independent availability alert works. Record each test with its date, scope, tester and outcome, and open tickets for any gap. The completed test set is the strongest evidence for an assessor, because it shows the chain works in practice and not only on paper. Testers can be internal or supported by an implementation partner, but the organization owns the results.

Evidence that passes IR 2024/2690 3.2 monitoring and logging

An assessor or competent authority testing point 3.2 will ask to see the monitoring system working, not just installed. The cards below cover the artifacts that show detection, alarm response, log protection and time integrity, and how to refresh each one between audits so the evidence reflects the current environment.

SIEM and EDR or XDR records

ENISA's June 2025 guidance lists SIEM systems and EDR or XDR tools as evidence sources. Export the configuration, the list of ingested log sources, and the detection rules in force, with their change history. Confirm which hosts, network devices and cloud services feed the platform, because an assessor will compare that list against your asset inventory. Re-export these records at each quarterly review so the source list matches what is actually running.

Log samples with point 3.2.3 elements

Keep dated samples showing that logs contain the elements point 3.2.3 asks for where appropriate: network traffic, user creation and permission changes, authentication events, privileged activity, access to critical configuration and backup files, and physical access events. Mark which element each sample covers. Replace samples on a fixed schedule so an assessor sees current formats, and note any source that cannot yet produce an element and the compensating control.

Configured alarm thresholds

Document each alarm threshold, the event pattern that triggers it, whether the alarm fires automatically, and who receives it. Point 3.2.4 expects a timely, qualified response, so record the response owner and the escalation path for each threshold. Store the rule definitions under version control, for example as Sigma or custom Wazuh rules, and review them after each significant change to the environment or threat landscape.

Records of past alarms and responses

An assessor will sample past alarms and ask what happened next. Keep each alarm record with its timestamp, the rule that fired, the triage notes, the analyst who responded, and the closure reason. OpenSearch Security Analytics stores findings with rule, log type and severity, and Wazuh writes alerts to alerts.log and alerts.json, so these exports can anchor the record. Include false positives and tuning decisions, since they show the review of unusual trends that point 3.2.4 requires.

Retention and log store access controls

Point 3.2.5 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes, but it sets no fixed period. Record the retention period you chose and the reason for it, the backup schedule, and the list of accounts that can read, modify or delete logs. Export the access control configuration and any integrity protection, and recheck the list of accounts on each access review. For Nextcloud, confirm the audit log path and permissions, since audit.log lives in the data directory unless a different path is set.

Time source configuration

Point 3.2.6 asks for synchronized time sources where feasible. Keep the configuration showing which time servers each system and monitoring component uses, and the drift checks that compare them. Without consistent timestamps, correlation across log types fails and incident timelines cannot meet reporting deadlines. Re-export the time configuration after infrastructure changes, and record any system that cannot synchronize along with the reason.

Independent availability alert history

Point 3.2.6 requires monitoring and logging systems to be redundant and their availability monitored independently of the systems they monitor. Keep the configuration of that independent watchdog, the alert history showing outages of the logging pipeline, and the response to each outage. Test the watchdog periodically and record the test results, because an assessor will ask whether a silent logging failure would be noticed.

What meeting monitoring and logging costs in effort and money

This table breaks the cost of meeting point 3.2 into 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 quote request and to see where self-hosted open-source tooling removes license spend while leaving infrastructure and staffing costs in place.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendor for commercial SIEM, EDR or XDR; none for most open-source platforms such as Wazuh or OpenSearch	Recurring for commercial licenses, usually tied to data volume or endpoints	Commercial pricing models vary; open-source options remove license fees but not support or hosting
Engineering time to build collection and detection	Internal platform team or an implementation partner under a written scope	One-time, with later changes as sources are added	Number of log sources, need for custom Sigma or Wazuh rules, and how many systems must be integrated
Storage and retention capacity	Organization, through its own cloud accounts, data centers or hardware	Recurring, growing with volume and retention length	Log volume per day, the retention period the organization sets for point 3.2.5, and backup copies of logs
Analyst time to review alarms and respond	Internal security operations staff or a managed SOC provider	Recurring, usually the largest ongoing item	Alarm noise, tuning quality, number of alarm thresholds, and whether response is automated where appropriate
Redundancy and independent availability monitoring	Organization, for a second logging path and a separate health check	One-time design, then recurring hosting and testing	Number of critical systems, whether monitoring runs on a separate network, and failover design
Time synchronization and log protection	Organization, for time sources, access controls and integrity protection of logs	One-time configuration, then recurring review	Number of hosts and devices, and how many people need access to log stores
Evidence upkeep	Internal compliance or security staff, sometimes with a partner	Recurring, tied to review cycles	Number of alarm records and log samples kept, and how often thresholds and configurations change
External testing or review	Independent testers or assessors, engaged under written scope	Recurring at the frequency the organization sets	Scope of the monitoring environment and whether detection is tested with simulated attacks
Auditor sampling	Independent auditor or certification body, not DeployOpen	Recurring at each assessment cycle	Number of log sources in scope and quality of evidence ready at the time of review

Open-source tools for monitoring and logging evidence

Point 3.2 asks for logs, alarm thresholds and a reviewable record of how alarms were handled. The tools below each produce a different slice of that record, from application audit trails to secret-access logs to detection and correlation. None of them covers the full point 3.2.3 list on its own, so the entity should map each tool to its own log sources before relying on it as evidence.

Nextcloud admin_audit app

The admin_audit app writes additional event information to an audit.log file in the data directory, or to a path set with logfile_audit. For point 3.2.3, this covers application-level access and administrative changes such as user and permission activity on a Nextcloud instance. Check that the events you need, including user creation and permission changes, are present in the log, and that the file is shipped off the host so it survives tampering with the server. Confirm the license terms with your legal team, because Nextcloud is AGPL-3.0-only and the obligations apply to modified versions offered over a network.

OpenBao audit devices

OpenBao audit devices record a detailed JSON entry for every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the log shows who accessed a secret and when without exposing the secret itself. This supports the point 3.2.3 expectations for access to critical configuration and privileged activity. Confirm that you have enabled at least one audit device, that logs leave the OpenBao host, and that the hashing covers the fields your assessor will ask about. OpenBao is MPL-2.0 licensed.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match becomes a finding with its rule, log type and severity, and alerts go to channels such as Slack or email. The correlation engine links findings across log types in a correlation graph, which helps an analyst reconstruct a sequence of events. Evidence to keep includes the configured detectors, the alarm thresholds and a record of past findings and responses. Confirm that the log types you collect have matching rules. OpenSearch is Apache-2.0 licensed.

Wazuh decoding and rule matching

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. The JSON alert file is useful evidence because it preserves the rule ID, timestamp and source for each alarm. Check that the decoders cover your actual log formats and that custom rules are version-controlled. Wazuh is GPL-2.0-only, so confirm how its license applies to your deployment and any modifications you make.

Who does what: your team, a partner and the auditor

Your organization remains accountable for monitoring and logging under point 3.2 of the Annex to Implementing Regulation (EU) 2024/2690, whoever installed the tools. Your security team decides which systems, accounts and events fall within logging coverage, sets alarm thresholds based on your risk assessment, and staffs the review and response process that turns alarms into timely, qualified action. Management approves these decisions and keeps the record of why they were made.

Coverage decisions: Deciding which of the point 3.2.3 log categories apply to each system, and documenting where a category is not applicable.
Threshold ownership: Setting and periodically revisiting alarm thresholds, and recording who approved each change.
Alarm response: Staffing review and triage, including out-of-hours coverage, and keeping records of past alarms and their outcomes.
Log protection and retention: Choosing the retention period for your context and holding the keys, access rights and backup arrangements for log stores.
Independent monitoring: Deciding how availability of the monitoring stack itself is watched by something other than the stack.

If you outsource any part of the response, such as a managed SOC, the contract should keep decision rights and evidence ownership with you. Confirm this before signing.

Questions buyers ask about monitoring and logging under NIS2

What drives the cost of monitoring and logging for NIS2?

The cost depends mostly on how many systems produce logs, how much data they generate, and how much of the monitoring must be automated. Point 3.2 requires procedures and tools to monitor and log activity on network and information systems, with monitoring automated to the extent feasible, so buyers pay for three things: the logging sources that must be configured, the platform that collects, correlates and alerts on events, and the people who review alarms and respond to them. Costs recur through storage, licensing or hosting, and ongoing rule tuning. Ask any provider for a quote that separates one-time setup from recurring platform, storage and support costs, and that names the log sources included. DeployOpen does not publish prices; a quote follows from a written scope.

How long does a monitoring and logging project take?

The timeline depends on the size of the estate, the number of log sources, and how mature the existing logging is. An organization with centralized logs and a working alert process has far less to build than one with logs scattered across hosts, cloud accounts and applications. No fixed duration applies under the regulation, so treat any timeline as an estimate to confirm against your own inventory of systems. The work usually runs in stages: identify required log sources, centralize collection, configure alarm thresholds, test that alarms fire, and document the review process. Agree the stages and deliverables in writing before work starts.

Can our own team implement NIS2 monitoring and logging without outside help?

Yes, a capable internal team can do this, provided it has the skills and time to configure collection, rules and alerting and to keep them current. Many of the tools in this area are open source and self-hosted, so licensing is rarely the barrier; the constraint is staff time and expertise. Outside help is most useful for scoping against point 3.2, building a working detection baseline, and testing that alarms and retention behave as described. Management still owns the controls and the decisions about thresholds and response. Whoever is chosen, the organization must be able to show that monitoring is running and reviewed.

What does monitoring and logging require from our staff day to day?

Someone must own the monitoring function, review logs regularly for unusual trends, and respond to alarms in a timely and qualified way. Point 3.2.4 requires regular review and a response to alarms that is timely and qualified, so the people involved need security knowledge and clear escalation paths. Expect recurring work in triaging alerts, tuning rules to reduce false positives, reviewing alarm records, and keeping log sources current as systems change. Define who is on call, what severity levels trigger action, and how reviews are recorded. Staff who only receive alerts without a documented response path will not meet the requirement in practice.

How long should we keep logs when NIS2 sets no fixed period?

The regulation does not set a retention period, so the period is one your organization must define, justify and apply consistently. Point 3.2.5 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes. Base the period on your risk assessment, sector rules, contractual obligations, and the time needed to investigate incidents and meet reporting timelines. Confirm the expectation with your national competent authority and any sector regulator, since they may apply their own practice. Whatever period you choose, document it in a policy, enforce it in storage, and test that logs can be restored from backup.

How should we prepare for a competent authority inspection on logging?

Prepare by being able to show, without delay, that logging and monitoring exist, run and are reviewed. Competent authorities oversee compliance through inspections, security audits, security scans and information requests rather than a certificate, so the evidence must be ready on request. ENISA's June 2025 guidance lists SIEM systems, EDR or XDR tools, log samples containing the point 3.2.3 elements, configured alarm thresholds and records of past alarms as examples of evidence. Assemble a log source inventory, sample logs, threshold configurations, alarm and review records, retention and access settings, and time synchronization configuration. Confirm with your authority which formats and depth it expects, because these requirements are applied through national transposition laws.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source monitoring and logging inside your own infrastructure, so the logs, alarms and log stores that point 3.2 asks about run where your data already lives. We prepare the systems and evidence; your organization owns the controls and decides what counts as an incident, and an independent assessor reviews the result.

How we scope

Written scope lists the systems, log sources and cloud accounts in your environment that point 3.2 monitoring must cover.
Scope records which point 3.2.3 log categories apply to each system, and where a category does not apply and why.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We deploy and configure the chosen logging and detection tools in your infrastructure, including time synchronization and separate monitoring of their availability.
We set alarm thresholds and detection rules, then test them with controlled events to confirm alarms fire and reach the responsible team.
We configure log protection, backup and retention settings to match the predefined period your organization sets and documents.

How we hand over

Handover includes configuration records, rule and threshold documentation, and a runbook for the regular log review your organization performs.
We provide sample log extracts showing each point 3.2.3 element, plus records of test alarms, as evidence your team can present.
Your organization reviews and accepts each deliverable, and retains ownership of the controls and the evidence they produce.

How we support

Ongoing support, upgrades and continuous testing of the monitoring stack are available as a retainer after handover.
Retainers can cover rule tuning, platform upgrades and periodic checks that logging remains redundant and monitored.
Ask any partner to confirm in writing which parts of the evidence will be assessed by your auditor or supervisor, and who reviews it.