Can a managed SOC carry NIS2 monitoring and the reporting clocks?
NIS2 does not name a managed SOC, and the obligation stays with your organization. A provider can run monitoring, prepare logs and evidence, and triage alerts, but your management body and named staff keep the decisions, the reporting duties and the accountability. Under Article 23, the 24-hour early warning and 72-hour notification run from the moment your entity becomes aware of a significant incident, so the contract must let the provider escalate to you in time for you to act. Whether a managed service carries this load depends on three things: how much monitoring capacity you already have in-house, which log sources you can bring under monitoring, and whether the provider can act within the clocks rather than merely report alerts after the fact.
Before you rely on a provider, check the monitoring scope against point 3.2 of the Annex to Implementing Regulation 2024/2690. Confirm which of the point 3.2.3 log categories (authentication, privileged activity, access to critical configuration and backup files, security tool logs and others) reach the provider's platform, who sets the alarm thresholds, and who owns the records of past alarms. Ask the provider to show a sample log set and an alarm history from a system similar to yours. Also confirm, in writing, how long logs are retained and where the backups sit, since the regulation requires protection from unauthorized access or change but sets no fixed retention period. Your own retention decision should be documented and approved by management.
NIS2 creates no certificate of compliance, so no SOC provider can offer one. Supervisory authorities check compliance through inspections, audits, scans and information requests, and only independent assessors or certification bodies issue reports. Treat any provider claim of NIS2 certification as a warning sign. Prices for managed monitoring depend on the written scope, so ask each vendor for a quote built on your log sources, hours of coverage, escalation paths and reporting support, and ask which costs are one-time (onboarding, log integration) and which recur (monitoring, retention storage, retainer hours).
Which log sources a managed SOC must cover for NIS2
Point 3.2.3 of the Annex to Implementing Regulation (EU) 2024/2690 lists the log categories an entity should capture where appropriate. The entity decides, with its provider, which of these sources fall in scope for its own systems, and the provider must be able to collect, retain and review what is agreed. The cards below set out each category, the gap we see most often in hybrid and self-hosted estates, and what to confirm during onboarding.
Network traffic
The provider needs flow or packet-level records from perimeter devices, internal segments and cloud virtual networks, so that lateral movement and data exfiltration can be seen. In self-hosted estates, east-west traffic between virtual machines or container hosts often goes unlogged because it never crosses a firewall. Confirm which network points feed the SIEM, the collection method for each, and whether the provider receives full records or only summaries.
User creation and permission changes
Every new account, role assignment and group membership change should reach the provider as an event with the actor, target and time. Gaps appear when directory changes are made locally on self-hosted applications that keep their own user stores, outside the central identity provider. Ask the provider to confirm which identity sources it ingests and how local application accounts are covered.
System and application access
Access events show who reached which system or application and when, and they are the first place to look when an attacker uses valid credentials. Self-hosted platforms frequently write access logs to local files that rotate before anyone forwards them. Confirm that each in-scope application ships its logs to the SIEM, with timestamps synchronized across hosts so events can be ordered during a reporting window.
Authentication events
Successful and failed logins, multi-factor challenges and token issuance form the record used to detect password spraying and session abuse. Hybrid estates often split authentication between cloud identity and on-premises directories, so no single log shows the full picture. Ask the provider to show correlated authentication events across both sources and to name the detection rules it applies to failed-login patterns.
Privileged activity
Actions taken with administrative rights, including sudo use, domain admin sessions and changes to security settings, carry the highest risk and need the closest review. Privileged sessions on self-hosted hypervisors and databases are often recorded only on the host itself. Confirm whether the provider receives session-level records for privileged accounts and whether break-glass accounts trigger immediate alerts.
Critical configuration and backup files
Access to critical configuration files and backup sets can reveal an attacker preparing to disable controls or destroy recovery points. Backup repositories are a common blind spot because they sit outside the production monitoring scope. Ask the provider how it monitors reads, writes and deletions on configuration stores and backup targets, and whether those alerts are routed to the same queue as other high-severity events.
Security tool and resource use logs
Logs from endpoint, firewall and monitoring tools show whether protections were disabled or tampered with, while resource use records reveal sudden spikes linked to cryptomining or data staging. Gaps appear when agents on self-hosted servers stop reporting and nobody is alerted. Confirm that the provider alerts on agent silence and on changes to tool configuration, not only on detections.
Managed SOC, MDR or incident response retainer: which fits your monitoring gap
This table compares an in-house SOC, a managed SOC (MSSP), MDR, an incident response retainer and a hybrid model across what the provider does, who holds the alarm decision, where logs live and when each fits. Read it as a starting point for questions to put to each provider in writing, since capabilities vary by vendor and contract.
| Option | What the provider does | Who holds the alarm decision | Where logs are stored | When it tends to fit |
|---|---|---|---|---|
| In-house SOC | Your staff run log collection, alert triage, investigation and response on your own SIEM and EDR tools | Your organization, through internal analysts and on-call rotation | Your own infrastructure or cloud accounts, under your control | Organizations with enough skilled staff to cover alarms and review thresholds around the clock |
| Managed SOC (MSSP) | Operates monitoring and alert triage for your SIEM or log platform, escalating to your team | Shared: the provider triages, your team decides on containment and reporting | Confirm with the provider: may be in your environment or in the provider's platform | Organizations with thin internal staff that still want to own the platform and response decisions |
| MDR | Monitors endpoints and networks with detection and response actions, often including containment within agreed limits | Shared, with pre-agreed response actions defined in the service terms | Confirm with the provider: often in the provider's platform, with export options to verify | Organizations that want active containment support and can accept a provider acting within pre-approved boundaries |
| Incident response retainer | Provides on-call forensic and response specialists during an incident, usually without continuous monitoring | Your organization, with the retainer team advising and executing agreed tasks | Evidence collected under your chain-of-custody procedures, stored where you direct | Organizations with monitoring in place but no forensic capability to call on for significant incidents |
| Hybrid model | Combines an internal team for daytime triage with an external provider for after-hours monitoring or retainer support | Split by shift or by incident type, documented in the response plan | Usually a central log platform with defined access for each party | Organizations that need continuous coverage but want to keep decisions and key evidence in-house |
| Provider access to your systems | Requires remote connections, credentials or agents in your environment | Your organization must authorize each connection and set its duration | Access logs should be retained and reviewed by your team | Applies to every option above: confirm time-limited access and approval steps in the contract |
How alarm thresholds and qualified response satisfy point 3.2.4
Point 3.2.4 of the Annex to Implementing Regulation (EU) 2024/2690 asks for three things working together: logs reviewed regularly for unusual trends, alarm thresholds that raise an alarm (automatically where appropriate), and a timely, qualified response once an alarm fires. A managed SOC or MDR provider can run the review and the alerting, but the entity must be able to show who set each threshold, why it was set there, and who acted. The threshold register is the document an assessor will ask for first. It should list each detection rule, the log source it reads, the threshold value, the owner on the entity side, the provider analyst group that triages it, and the date of the last review.
Responsibilities for tuning should be split in writing. The provider usually proposes thresholds from its detection content and the entity's asset inventory, but the entity approves changes, because a threshold that is too loose hides incidents and one that is too tight floods the queue until analysts stop reading it. The contract or runbook should set the escalation path: which alarms are closed by the provider, which are escalated to a named internal contact, how that contact is reached out of hours, and what counts as a qualified response. Records of past alarms, including closed false positives with the reason for closing, are the evidence ENISA lists for this point. Ask the provider to show a sample of closed alarms with timestamps and analyst notes, and check that the sample includes at least one escalation.
Point 3.2.5 covers the logs themselves: they must be kept and backed up for a predefined period and protected against unauthorized access or change. The regulation sets no fixed retention period, so the entity must choose one, document it, and justify it against its own obligations and the reporting clocks it may need to support. Confirm with the provider where logs are stored, who holds administrative access to the log store, whether write-once or immutable storage is used, and how integrity is checked. Retention should be written into the service agreement, including what happens to logs when the contract ends. Confirm these details in the provider's contract and runbooks rather than assuming them.
Running the 24-hour and 72-hour clocks with a provider
This sequence turns a provider alert into a timed, signed NIS2 reporting decision, so the entity can meet the 24-hour early warning and 72-hour notification deadlines with a record that shows how each decision was made. The entity owns every submission, even when the provider does the technical triage.
Agree escalation contacts and the awareness definition
Before any alert arrives, the entity and the provider agree in the contract who receives escalations at each hour of the day, who can make a significance decision for the entity, and what event counts as the entity becoming aware of a significant incident. The clock under Article 23(4) starts from that awareness point, so the definition should be written down and tested. The output is a signed escalation matrix and a contract clause that names the entity's decision owner, usually a named security officer with a deputy. The step is done when both parties have signed the matrix and a named person confirms they can be reached out of hours.
Triage and classify the alert
The provider's analysts review the SIEM or EDR alert against the alarm thresholds and log evidence the entity has configured, then decide whether it is a false positive, a routine event or a possible incident. Each alert ticket should record the source logs, the affected systems, the analyst's reasoning and the time of first detection. The output is a classified ticket with a timestamp that the entity can reproduce later. The entity's security officer confirms the classification or asks for more analysis before the ticket moves on.
Decide whether the incident is significant
The entity, not the provider, decides whether the event is a significant incident under the NIS2 criteria in the implementing regulation. The provider supplies facts such as affected services, data exposure and scope, and the decision owner records the outcome, the criteria applied and the reasons. The output is a signed significance assessment with a time stamp. If the decision is unclear, the entity should treat the case as potentially significant while it gathers facts, because the early warning clock is already running.
Submit the early warning within 24 hours
If the entity has become aware of a significant incident, it must submit an early warning without undue delay and in any event within 24 hours. The entity submits the warning through its national reporting channel, using its own account and credentials, and the provider prepares the draft facts. The output is a copy of the submitted warning, the submission receipt and the time it was sent. The step is closed only when the entity holds a receipt that falls within the 24-hour window.
Submit the incident notification within 72 hours
Within 72 hours of becoming aware of the significant incident, the entity submits an incident notification that updates the early warning with an initial assessment, severity, impact and indicators of compromise where available. The provider supplies the technical analysis, and the entity checks it against its own records before signing. The output is the signed notification, its submission receipt and a list of any corrections made since the warning. Where the nature of the incident requires it, the entity should also consider whether service recipients must be informed under Article 23.
Keep the record and close the case
The entity keeps a single incident record that links the alert, the classification, the significance decision, both submissions and the final report that follows. The provider's logs, ticket history and analysis notes are retained under the entity's retention rules and protected from unauthorized change. The output is a closed case file that a competent authority could review without relying on the provider's systems. The step is complete when the record is indexed, the provider has handed over its evidence, and lessons learned are assigned to an owner.
Rehearse the sequence in an exercise
Run a tabletop or live exercise that starts with a realistic alert from the provider's monitoring, then walks through each step, including an out-of-hours escalation and a decision where the facts are incomplete. Time each handoff against the 24-hour and 72-hour clocks and record where contacts, approvals or evidence were slow. The output is an exercise report with gaps, owners and dates for fixes. The sequence is only proven when a second exercise passes without the same gaps.
Who does what: management, your team, the managed SOC provider and the assessor
The management body approves the risk-management measures, including how logs are monitored, what alarm thresholds mean for the business, and how the reporting clocks are run. Under NIS2 the management body keeps accountability for compliance even when a provider runs the monitoring day to day. Management does not need to operate the SIEM, but it must understand what the provider covers and decide what the organization accepts as risk.
- Approves the monitoring scope: agrees which systems, log sources and retention periods sit inside the managed service and which do not.
- Sets decision rights: names who may declare a significant incident and who signs off the early warning and notification.
- Accepts residual risk: decides which alarms are tuned out, which gaps remain open and for how long.
- Oversees the provider: reviews the provider's reports, service reviews and any changes to contract terms at regular intervals.
- Completes training: takes part in the cybersecurity training the management body must follow.
Check that the minutes of management meetings show a real review of the monitoring arrangements, not only approval of a purchase order.
The internal security team owns the controls that the managed service relies on. It decides which logs the organization generates, makes sure systems are configured to send them, and acts as the single point of contact for the provider. When an alarm reaches the organization, the internal team decides whether it is a significant incident and triggers the reporting process. Most organizations keep this role in-house even when monitoring is outsourced.
- Owns log sources: configures endpoints, cloud accounts, identity systems and applications to produce the logs the provider needs.
- Runs the incident decision: classifies alerts and decides whether a significant incident has occurred, documenting the reasoning.
- Manages provider access: requests, approves and removes provider connections, and confirms each access is time-limited.
- Keeps the evidence: retains the configuration records, alarm histories and tickets that show the monitoring works.
- Tests the process: runs exercises that walk the team through detection, escalation and the 24-hour and 72-hour clocks.
Confirm who in the internal team holds the authority to make the reporting decision when the provider is unreachable outside business hours.
A managed SOC or MDR provider monitors logs and endpoints, triages alerts, and escalates events to the organization. Recital 86 of NIS2 notes that managed security service providers are closely integrated into operations, which is why the entity must select them with increased diligence. The provider does the monitoring and prepares evidence, but it does not decide the organization's compliance position or make its reporting decisions.
- Monitors and triages: reviews alarms against agreed thresholds and responds within the timings in the service agreement.
- Escalates in time: notifies the named internal contacts so the organization can meet the 24-hour early warning clock.
- Prepares evidence: produces SIEM and EDR records, alarm logs and reports that show how monitoring performed.
- Protects its own access: uses only the access granted for the agreed period and logs every session.
- Discloses its own security: provides its controls, certifications and incident history for the diligence process.
Verify in the contract that the provider's evidence is delivered in a format the organization can give a supervisor without the provider's involvement.
An independent assessor or auditor tests whether the controls work and issues any report or certificate. NIS2 creates no certificate of compliance, so no assessor can certify NIS2 compliance in the way a certification body issues an ISO certificate. The assessor's value lies in testing the evidence independently of the people who produced it. Neither the managed SOC provider nor an implementation partner can play this role for the same environment.
- Tests independently: samples logs, alarm thresholds and incident records without relying on the provider's summaries.
- Reviews provider oversight: checks that the organization monitors the provider's performance and access.
- Issues the report: provides findings in writing under its own name, where the engagement calls for a report.
- Stays separate: avoids designing or operating the monitoring it later assesses.
- Reports gaps: records exceptions for management to address.
Ask any assessor to confirm in writing which parts of the engagement it can accept without a conflict of interest.
MSSP due diligence: what to check before signing with a managed security provider
Recital 86 of NIS2 asks entities to take increased diligence when selecting managed security service providers, because their close integration into daily operations creates particular risk. The cards below turn that expectation into questions to put to a provider and the evidence a sound answer should include. Treat each answer as part of your own supplier file, since the organization remains accountable for its monitoring and reporting duties.
Security assurance evidence
Ask which independent assessments cover the service that will touch your logs and alerts, and for what scope and period. Good evidence is a current report or certificate that names the in-scope services, plus the provider's remediation status for any open findings. Confirm the scope matches the service you are buying, not the provider's whole company. Ask for the results of its own penetration tests on the monitoring platform, with the date and the tester's identity. Verify credentials directly with the issuing body rather than accepting a copy.
Provider supplier controls
Ask which subcontractors, cloud platforms and software components the provider relies on to deliver monitoring, and how it assesses each one. A useful answer lists sub-processors, their locations, the security terms in those contracts and how often the provider reviews them. Chains of unnamed third parties mean your monitoring data may pass through parties you never assessed. Ask how the provider will notify you when it changes a critical supplier, and whether you can object before the change takes effect.
Incident notification to the customer
Ask how quickly the provider will tell you about a security incident in its own environment, and through which channel. Your 24-hour early warning and 72-hour notification clocks start when you become aware of a significant incident, so a provider that waits to tell you delays your own reporting. Write the notification window, the named contacts and the out-of-hours escalation path into the contract. Ask for a sample of how the provider has documented its past incidents affecting customers.
Data location and log custody
Ask where logs are stored, processed and backed up, which legal jurisdictions can compel access to them, and who holds the encryption keys. Point 3.2.5 of the Annex requires logs to be kept, backed up and protected from unauthorized access or changes, so custody terms must be explicit. Confirm that you can export complete log sets in a usable format, and that retention is set by you, not by the provider's default. Ask what happens to your data at the end of the contract.
Staffing and qualifications
Ask who will analyze your alerts, how many analysts are assigned to your account, and what training and certifications those individuals hold. Find out whether analysts work around the clock or escalate after hours, and how the provider handles staff turnover on your account. Request the named roles for your engagement and the qualification evidence for each. Confirm that the people who can see your data are subject to background checks and confidentiality obligations that your contract recognizes.
Access, exit and handover terms
Ask how the provider accesses your environment, what it can change, and how that access is authorized, time-limited and logged. Point 6.7.2(h) of the Annex allows service provider connections only after an authorization request and for a set period. Exit terms should require a complete handover of logs, alarm thresholds, detection rules, incident records and configuration, delivered before access is removed. Ask for the written exit plan and confirm that access revocation is verified, not assumed.
Time-limited provider access and the evidence a managed SOC should hand over
Point 6.7.2(h) of the Annex to Implementing Regulation (EU) 2024/2690 allows a service provider connection only after an authorization request and only for a set period, such as the duration of a maintenance operation. For a managed SOC or MDR provider, that means the connection into your SIEM, EDR console or log pipeline should never be a standing account. Before go-live, agree a written access procedure with the provider: who requests access, which systems and roles it covers, the start and end time of each window, and who in your organization approves it. Record each request and approval in a ticket or change record, and link it to the monitoring activity it supported. Revocation should be tested, not assumed: confirm that accounts, API tokens and VPN routes expire or are removed at the end of the window, and keep the removal record as evidence.
Once the provider is connected, ask for the records that show monitoring works as described. ENISA's June 2025 guidance lists SIEM and EDR or XDR records among the examples of evidence, so request exports or read-only views from those platforms showing what is collected and what raised alerts. Ask for log samples that contain the point 3.2.3 elements, such as authentication events, privileged activity and security tool logs, and check that each element is present for your environment. Also request the alarm thresholds as configured (not as described in a proposal), and the records of past alarms with their triage notes and response times. Under point 6.7.2(h), the provider's own access history to your systems is part of the same evidence. Request these before go-live and again at every periodic review, because a threshold changed in a quiet month is exactly what a supervisor will ask about.
What delays a managed SOC rollout for NIS2 and how to avoid it
Most delays in a managed SOC rollout come from decisions made before the first alert fires: what counts as awareness, which systems send logs, how alarms are set, and who can reach the environment. Each card below names one of these gaps, the cost it creates, and the control that closes it.
Unclear awareness for the clocks
The 24-hour early warning and 72-hour notification run from the point the entity becomes aware of a significant incident. If the SOC, the internal team and the management body have not agreed when awareness starts, the provider may triage for hours while the internal clock has already moved. Write down who declares an incident, which provider signal starts the clock, and how the provider's escalation reaches the named reporting owner outside working hours. Test this with a tabletop exercise before go-live.
Log gaps in cloud and on-premises systems
A SOC can only detect what reaches it. Gaps often sit in SaaS administration consoles, legacy on-premises servers, firewalls, backup systems and physical access or environmental feeds, all listed among the elements point 3.2.3 expects where appropriate. Build a log source inventory that maps each system to its log type, collection method and owner, then ask the provider to confirm coverage for each row. Missing sources surface during an incident, when they are most expensive to fix.
Alarm thresholds never tuned
Default detection rules either flood analysts with noise or stay silent on the unusual trends that point 3.2.4 asks entities to review. Thresholds set once at onboarding and never revisited make alarm records weak evidence, because an assessor will ask why a given threshold was chosen and whether it was reviewed. Agree a written threshold register with the provider, record each change with its reason, and review the register on a fixed schedule and after any significant incident.
Provider access left open
Remote access for a managed SOC or MDR provider can persist long after onboarding, which leaves a privileged path into production. Point 6.7.2(h) expects service provider connections to be allowed only after an authorization request and for a set period, such as the length of a maintenance task. Require named accounts, multi-factor authentication, just-in-time approval with an end date, and session logging. Ask the provider to show how access was revoked at the end of its last window.
No tested escalation path
A SOC that detects an event is only useful if the entity can act on it within the reporting clocks. Unclear hand-offs between the provider, the internal incident lead, legal, the DPO and the national authority cause the most delay in practice. Document a contact tree with out-of-hours coverage, decision rights for containment, and a reporting template that matches Article 23. Then run the path end to end and keep the timestamps, since they form the evidence a supervisor will ask for.
Unclear log retention
Point 3.2.5 requires logs to be kept and backed up for a predefined period and protected from unauthorized change, but it sets no fixed retention period. Entities that leave retention to the provider's default may find logs gone when a supervisor asks for history, or may keep them longer than their own policy allows. Set the period in the logging policy, confirm where the provider stores logs and in which jurisdiction, and check that integrity protection and access controls on the archive are described in writing.
Managed SOC and NIS2 questions buyers ask before hiring
Does NIS2 require a managed SOC?
No. NIS2 does not name a managed SOC, an MDR service or any particular type of monitoring provider. What it requires is that the entity runs procedures and tools to monitor and log activity on its network and information systems, detects events that could be incidents, and can report significant incidents within the deadlines. Whether that monitoring is run by an in-house team, a managed service or a mix is the entity's decision. Point 3.2 of the Annex to Implementing Regulation (EU) 2024/2690 sets the technical expectations, and the management body remains accountable for the choice. A managed service is one way to meet them, and it needs the same diligence as any other critical supplier.
What drives the cost of a managed SOC or MDR service?
The price follows the written scope, so no fee can be stated in general terms. The main drivers are the number and type of log sources, the number of endpoints and cloud accounts covered, whether the provider performs active response or only triage and escalation, the hours of coverage, and how much of the incident handling and reporting support is included. Some costs are one-time, such as onboarding, log source integration and detection tuning. Others recur, such as monitoring, licensing for the security tooling and retainer hours for incidents. To get a comparable quote, ask each provider to price the same list of log sources, the same alarm handling model and the same reporting support, and to state what the entity must supply itself. DeployOpen does not publish a price list. A quote follows from a written scope agreed before work starts.
How long does onboarding a managed SOC take?
The timeline depends on the state of the environment and the scope agreed in writing, so it cannot be fixed in advance. The longest steps are usually inventory of assets, connecting log sources to the monitoring platform, agreeing which events are alarms and who receives them, and testing that the escalation path works outside business hours. Access approvals, change windows and any data residency constraints can also add time. Ask the provider for a written onboarding plan with milestones, the entity tasks on the critical path and the point at which monitoring is considered live. Confirm whether the reporting contacts, the 24-hour and 72-hour procedures and the evidence hand-over are part of go-live, because they are often treated as later phases.
What must the entity still do itself when using a managed SOC?
Outsourcing monitoring does not transfer responsibility for NIS2 compliance. The entity still needs to:
- Decide the risk-based scope of monitoring and approve it at management level.
- Own the decision to report a significant incident to the competent authority and the service recipients, even when the provider prepares the notification.
- Keep its own logs and records, and set the retention period, since the regulation sets no fixed period but requires logs to be kept, backed up and protected.
- Govern provider access, approve each remote connection for a defined period, and review what the provider did.
- Maintain its incident response plan, contacts and exercises.
The management body must also keep the oversight duties that come with any outsourced security function. An outside consultant or auditor can review this work, but cannot take the decisions.
Can a managed SOC provider handle the 24-hour and 72-hour reporting deadlines?
A provider can detect, triage, document and prepare the reporting material, but the entity must submit the early warning within 24 hours and the incident notification within 72 hours of becoming aware of a significant incident, as set out in Article 23 of NIS2. Before contracting, confirm in writing who makes the awareness judgment, how quickly the provider escalates to named entity contacts, who has authority to submit to the national authority, and what happens outside business hours. Test this with a tabletop exercise that starts from an alert and runs through the early warning. The provider's role should be written into the incident response plan, not left to the contract alone.
What evidence will an auditor or supervisor ask to see from the monitoring service?
Supervisors and assessors look for proof that monitoring works in practice, not only a contract. Typical evidence includes the SIEM and EDR or XDR configuration, log samples showing the elements listed in point 3.2.3 of Implementing Regulation (EU) 2024/2690, the configured alarm thresholds and the records of past alarms with the response taken. ENISA's June 2025 guidance lists these as examples of evidence. The entity should also be able to show the provider's access approvals and their expiry, the supplier diligence file, the service reports and the incident records from past exercises or real events. Read the ENISA technical implementation guidance to confirm the current examples before building the evidence pack.
How DeployOpen prepares logging, alarm and evidence for NIS2 monitoring
DeployOpen plans, implements, integrates and documents self-hosted open-source monitoring inside the client's own infrastructure, so logging, alarm thresholds and evidence are built to fit the entity's environment. Work is agreed through a written, fixed scope, and DeployOpen does not issue audit reports or certifications; the entity's management, its managed SOC or MDR provider and its independent assessor keep their own roles.
How we scope
- We confirm which systems, networks and cloud accounts fall within the written scope for monitoring and logging.
- We map log sources against the point 3.2.3 categories of Implementing Regulation 2024/2690 and record any gaps.
- We agree with the client which alarm thresholds, escalation paths and reporting contacts the 24-hour and 72-hour clocks will use.
How we build
- We deploy and integrate SIEM, EDR or XDR tooling in the client's own environment, with configured log collection and retention.
- We configure alarm thresholds and automated alerts, and document how each alert is triaged and escalated to a qualified responder.
- We protect logs against unauthorized access or change and set up backups for the retention period the client defines.
How we hand over
- We deliver written runbooks covering monitoring, alarm handling, incident escalation and the Article 23 reporting workflow.
- We produce evidence packs: sample logs with the required elements, configuration exports, threshold records and records of past alarms.
- We provide a handover on provider access, including authorization requests and time-limited connection rules for any managed SOC or MDR provider.
How we support
- Ongoing support, upgrades and continuous testing of the monitoring stack are available as a retainer.
- We can run exercises that test whether alarms reach the right people within the reporting windows, with results documented for the client.
- Where a client needs independent review, we prepare the systems and evidence for an independent assessor, who alone issues any report.
