Safeguard 13.1 Centralized security event alerting: evidence

What Safeguard 13.1 asks for and why an assessor starts with coverage

Safeguard 13.1 applies to enterprises in Implementation Group 2 and Implementation Group 3, so an IG1 organization can treat it as a later step rather than a day-one requirement. For IG2 and IG3 enterprises, the requirement is that security event alerts come from one central place instead of from each system on its own. The aim is to collect security-relevant logs from across the enterprise so that events from different sources can be correlated and analyzed together. CIS places the Safeguard in the Network asset class and the Detect security function, which tells an assessor that the evidence should show detection capability across network-connected assets, not only a policy statement that logs exist.

The assessment specification measures this Safeguard with a Coverage metric: the share of assets whose security logs are centralized. An assessor therefore starts with the asset list, not the tool. Before testing coverage, the assessor expects the Safeguard 1.1 enterprise asset inventory and the Safeguard 2.1 software inventory to exist, because a coverage percentage is meaningless without a denominator. Ask your team to confirm that the inventory is current, then compare it against the list of sources forwarding logs to the central platform. Servers, network devices, cloud workloads and remote endpoints that send nothing are the usual gap, and they lower the score even when the SIEM itself is well configured.

The specification also treats the absence of a tool as a failure. If the enterprise has no log correlation or log analytics tool, the Safeguard receives a failing score regardless of other maturity. A SIEM with vendor-defined correlation alerts is the reference model, and a log analytics platform configured with security-relevant correlation alerts is also accepted. Before any audit, confirm which platform will serve as the central point, which asset classes feed it, and who reviews the alerts it produces. Open-source options such as OpenSearch Security Analytics and Wazuh can serve this role, but you should verify each platform's capabilities against your own environment before you rely on it for evidence.

Which assets, logs and teams fall inside Safeguard 13.1 scope

Safeguard 13.1 applies to IG2 and IG3 enterprises, and its scope is set by the asset and software inventories that come before it. The cards below cover the decisions that determine which sources feed the central platform, who acts on the alerts, and what the assessment will count.

Confirm IG2 or IG3 applies

Safeguard 13.1 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1-only organizations. Confirm your group against the CIS Implementation Groups before committing budget. An IG1 organization can still collect logs for its own investigations, but it does not need to meet this Safeguard to claim IG1 coverage. Record the decision and its reasoning in the scope document so an assessor sees the same boundary you did.

Asset inventory as the boundary

The assessment treats Safeguard 1.1, the detailed enterprise asset inventory, as a prerequisite. Every asset in that inventory is a candidate source, and an asset missing from it is an asset nobody measures. Reconcile the inventory against cloud accounts, DHCP leases and directory records before you set the coverage denominator. Note which assets are excluded and why, since the coverage metric depends on that list.

Software inventory and application logs

Safeguard 2.1 requires a software inventory, which tells you which applications generate security-relevant logs. Business applications, identity providers and database engines often hold the events that matter most for correlation, such as failed logins and privilege changes. Map each inventoried application to its log output and decide whether it sends events centrally. Applications that cannot forward logs should be listed as exceptions with a compensating collection method.

Endpoints, servers and network devices

Endpoints, servers, firewalls, routers and switches are the core sources for the alerting platform. Network devices matter because they record traffic and access events that endpoint logs miss. Decide which device classes forward syslog or agent data, which use a collector, and which are out of reach. Check that time sources are consistent across these sources, because correlation across hosts fails when timestamps disagree.

Cloud and SaaS log sources

Cloud control planes, identity platforms and SaaS applications produce audit events that sit outside your network. Assets in these environments count toward the coverage metric when they are part of the enterprise inventory. Confirm which audit logs each provider exposes, how long the provider retains them, and whether you can export them to your central platform. Where export is limited, document the gap rather than assuming the provider's console counts as central alerting.

Team that owns alert triage

Central alerting produces work only if someone is assigned to review it. Name the security operations team or on-call role that owns triage, and document who can change correlation rules and who approves those changes. Clarify how alerts reach incident responders under Control 17, since an alert with no owner is treated as a gap in practice. Keep the roster and escalation path current, because assessors ask who acts on alerts.

SIEM or log analytics platform: choosing the centralization model

A commercial SIEM with vendor-defined event correlation alerts is the model CIS describes as best practice for Safeguard 13.1. The product ingests logs from every enterprise asset class in scope, normalizes them, and applies correlation rules that ship with the vendor's content library, which the team then tunes. The assessor's question is whether the SIEM actually receives logs from the assets the inventory in Safeguards 1.1 and 2.1 says exist, because the Coverage metric is the share of assets whose security logs are centralized.

Coverage proof: Keep a per-source onboarding record that matches each log source to an asset in the inventory, so the Coverage figure can be reproduced.
Vendor content: Confirm which correlation rules ship by default, how often they are updated, and whether they map to the detections you need.
Licensing model: Ask whether pricing scales with ingested volume, event count or assets, and what happens to retention when volume rises.
Data residency: Confirm where logs are stored and processed, and whether the vendor can deploy in your region or in your own cloud account.
Exit path: Confirm export formats for raw logs and alert history so evidence survives a change of vendor.

Before buying, ask the vendor for a written list of supported log sources and a test that proves correlation alerts fire on a sample attack sequence.

How an assessor tests centralized alerting coverage

An assessor testing Safeguard 13.1 starts from the asset inventory, not the SIEM console. The assessment specification treats the detailed enterprise asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1 as prerequisites, so the assessor first confirms both exist, are current and cover the assets in scope. The assessor then compares that inventory against the log sources actually feeding the central tool, such as endpoint agents, servers, network devices, cloud audit trails and identity systems. Gaps between the two lists are where the coverage score is lost. Ask your team to produce this comparison before the assessor does, with each asset marked as forwarding, not forwarding, or not applicable and a reason recorded for each exception.

The scored measure is Coverage: the share of assets whose security logs are centralized. The assessor divides the count of inventoried assets with logs arriving in the central platform by the total in scope, then samples a set of assets and checks the ingestion timestamps and log types to confirm the feed is live rather than configured once and abandoned. Expect questions about devices that are intermittently connected, remote endpoints and short-lived cloud workloads, because these are where inventories and feeds usually drift apart. Confirm your own exclusion rules in writing and agree them with the assessor early, since an undocumented exclusion looks the same as a missing feed.

Collection alone does not pass. The assessment specification fails Safeguard 13.1 if the enterprise has no log correlation or log analytics tool, and the assessor will also look for correlation alerts that exist and fire. In practice that means reviewing the rule set for security-relevant correlations, such as repeated authentication failures followed by a successful login, then tracing a test event through to an alert. A platform that stores logs with no correlation rules gives an investigator a searchable archive, not an alerting capability, and it fails the test as written. Before the assessment, run a controlled test event for each rule category, record the alert and its recipient, and keep the results as evidence.

What assessors request and where findings usually come from

This table compares what an assessor typically tests for Safeguard 13.1, the evidence they ask for and the gaps that most often produce findings. Read each row as a question the assessor will ask, then check whether your environment can answer it with dated, exportable records.

Test area	Evidence requested	Where findings usually come from
Coverage calculation	Asset inventory export from the Safeguard 1.1 process, paired with a list of assets whose security logs reach the SIEM or log analytics platform, with the share calculated	Inventory and log source lists were built separately, so the denominator and numerator do not match. Cloud workloads and short-lived instances are often missing
Correlation rule inventory	Exported list of active correlation rules or detectors, with owner, data source, last change date and the approval record for each	Rules exist in the platform but no current list is kept, or rules are disabled silently after an upgrade. Default vendor rules are never reviewed for the environment
Sample alert trace	For a selected sample alert, the raw log event, the rule that matched, the alert record, and the ticket or response action that followed	The alert fires but the trail stops at the dashboard. Assessors cannot see who reviewed it or what action was taken
Log source versus inventory gap	Reconciliation showing each asset in the inventory, its log source status and the reason for any exclusion, approved by the asset owner	Inventory shows assets that send no logs, and no exception record explains why. Shadow or unmanaged assets appear in traffic but not in either list
Prerequisite inventories	Current asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) that the test depends on, with evidence of their review cycle	Prerequisite inventories are stale or incomplete, which weakens every coverage figure built on them
Failing condition check	Evidence that a log correlation or log analytics tool is deployed and in use across the stated scope	No tool is in place for part of the estate, or a tool exists but was never configured with security-relevant correlation alerts
Documented process	Written procedure for onboarding log sources, reviewing alerts and handling escalations, with records of the most recent review	Procedures describe intent but do not match how the team works, or there is no record that the process was followed

How to centralize alerting in a self-hosted environment

This sequence moves from the asset and software inventories to a working central alerting platform, with each step ending in a named artifact that an assessor can check against Safeguard 13.1. It is written for teams running self-hosted open-source platforms inside their own infrastructure.

Confirm the asset and software inventories
Before any log source is connected, the organization confirms the detailed enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1), because the assessment specification treats both as prerequisites for measuring 13.1. The owner of each inventory signs off that it covers the hosts, network devices, cloud services and applications that will feed the central platform. The output is a reviewed asset list tagged by asset class (Devices, Software, Data, Users, Network or Documentation), which becomes the scope list for every later step. Done means each in-scope system has an owner and an inventory record.
Select the central platform
The security team chooses between a SIEM and a log analytics platform configured with security correlation alerts. CIS describes a SIEM with vendor-defined correlation alerts as best practice and accepts a log analytics platform with security-relevant correlation alerts. Candidate open-source options include OpenSearch with Security Analytics and Wazuh, and each should be checked against the log types and volumes the organization expects, and against its own support and hosting model. The output is a written platform decision record naming the product, version, hosting location and the owner responsible for it. Confirm the chosen product's current capabilities with its vendor or documentation before committing.
Onboard log sources by asset class
Engineers connect log sources in the order of the asset classes, starting with the highest-risk assets in scope, such as identity, network and administrative systems. Application audit logs are a common example, for instance the admin_audit app in Nextcloud writes to audit.log in the data directory or a path set with logfile_audit, and OpenBao audit devices produce JSON logs of API requests with most sensitive values hashed. Each source is recorded with its asset ID, log type, collection method and the person who approved it. The output is a source register that maps every onboarded log stream to an inventory entry.
Define correlation alerts
The detection team writes or enables correlation rules that link events across log types, such as failed logins followed by privileged activity from the same host. OpenSearch Security Analytics runs detectors against Sigma rules and links findings through a correlation engine, while Wazuh compares events against its built-in ruleset of over 3,000 rules and decoders plus custom rules and maps alerts to MITRE ATT&CK. Each rule is documented with its purpose, data sources, severity and owner. The output is a versioned rule set that an assessor can read alongside the alerts it produces.
Route alerts to triage
Alerts are sent to the people who will act on them through channels such as Slack or email, or through the incident ticketing process. The team defines severity levels, triage ownership and the hand-off to incident response, which connects this safeguard to the incident management controls. The output is a routing matrix showing which alert source and severity go to which queue, with a named on-call owner. Test the routing with sample events and record the result, so the team can show that an alert reached a person and was handled.
Record coverage for the Coverage metric
The assessment specification scores Safeguard 13.1 on the share of assets whose security logs are centralized, so the team calculates coverage by comparing the source register with the in-scope inventory. Each asset is marked as centralized, pending or excluded with a reason, and gaps are assigned owners. The output is a coverage report dated and signed by the control owner, which is the primary evidence an assessor will request. Keep the report and the source register under change control so the figure can be reproduced later.

Evidence that shows centralized alerting is working

An assessor testing Safeguard 13.1 will look for proof that logs from enterprise assets actually reach the platform, that correlation rules exist and change under control, and that alerts lead to documented action. The cards below cover the artifacts that carry that proof and how to keep each one current between assessments.

Coverage report against the asset inventory

This report compares the assets in your detailed inventory (Safeguard 1.1) against the assets whose security logs are arriving at the platform. The Coverage metric in the CIS assessment specification is the share of assets with centralized logs, so this is the artifact that answers it directly. Regenerate it on a fixed schedule, and investigate any asset that appears in the inventory but never sends logs, since silent sources are the usual gap.

Source onboarding records

For each log source, keep a record of when it was connected, who approved it, which log types it sends, and the parser or decoder that reads it. Assessors use these records to confirm that new hosts, network devices and cloud services are onboarded as part of provisioning rather than discovered later. A short checklist attached to change tickets is usually enough to keep these records complete.

Correlation rule set with version history

Export the correlation and detection rules from the SIEM or log analytics platform and store them in version control with change approvals. Confirm that each rule records its owner, the log types it depends on and the severity it raises. Because the assessment checks that correlation alerts exist, a rule set with dated commits shows both that alerts are configured and that they are maintained.

Sample alerts with triage tickets

Keep a sample of alerts from each rule family, each linked to the ticket showing who triaged it, what they found and how it was closed. An alert with no ticket shows that the output is not being reviewed. Choose samples across severities and time periods, and include at least one false positive with the tuning change it triggered, since that links alerting to the monthly threshold review in Safeguard 13.11.

Platform access and audit logs

The alerting platform holds sensitive security data, so its own logins, role changes, rule edits and configuration changes must be logged and reviewed. Confirm that these logs are forwarded to a location the platform administrators cannot silently edit. Wazuh writes alerts to alerts.json, and OpenSearch records findings, but your team must confirm which administrative events each product records and retains.

Keeping evidence current between audits

Assign an owner to each artifact and set a recurring date to refresh it, with the coverage report and rule export at least quarterly and the sample alerts drawn from each month. Store dated snapshots in a restricted evidence repository so that the state at any past date can be shown. Ask your assessor early which period and sampling method they will use, and confirm that your platform can produce historical exports for that window.

How OpenSearch, Wazuh and audit logs produce the evidence

The evidence for Safeguard 13.1 is a record that logs from enterprise assets reach one place and are matched against correlation rules, so a reviewer can see both the feed and the alerts it produced. Open-source platforms can supply both halves, but they supply different parts of the chain. OpenSearch Security Analytics handles the detection side: its detectors take ingested logs from hosts, network devices and cloud services, match them against prepackaged or custom Sigma rules, and record each match as a finding with its rule, log type and severity. Alerts can go to channels such as Slack or email, and the correlation engine links findings across log types into a correlation graph, which is the closest open-source analogue to the vendor-defined correlation alerts that CIS describes for a SIEM. The OpenSearch project is licensed under Apache-2.0, which permits commercial use, but your counsel should still confirm the terms that apply to the distribution you deploy.

Wazuh, licensed under GPL-2.0-only, can act as the collection and detection agent that feeds that pipeline. It decodes each collected log and compares the event against a ruleset of more than 3,000 built-in rules and decoders plus any custom rules you write. Matches are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. GPL-2.0-only carries copyleft obligations if you modify and distribute the software, so the licensing review should happen before you change Wazuh code or ship it inside a product. Whether Wazuh or OpenSearch Security Analytics fits your estate depends on your log volumes, retention needs and existing tooling, which you should test against a sample of real sources before you commit.

Source logs are the other half of the evidence, and they are only as good as the sources you configure. Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, so confirm that the app is enabled and that the file is shipped to your collector. OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. Confirm which audit device is enabled, where it writes, and who can read it. An assessor will ask whether each in-scope asset appears in the coverage count, so keep a list that maps each source to its asset record from Safeguards 1.1 and 2.1, and document which sources are not yet forwarded and why.

Open-source tools that support centralized alerting evidence

This table compares four open-source tools named in the researched facts for Safeguard 13.1, showing what each produces or supports as evidence and its license. Read it as a map of where centralized alerting evidence can come from, not as a claim that any one tool satisfies the Safeguard alone. Confirm each tool's fit against your own log sources and the CIS Controls Assessment Specification before relying on it.

Tool	How it produces or supports evidence	License
OpenSearch Security Analytics	Detectors match ingested logs from hosts, network devices and cloud services against Sigma rules, record findings with rule, log type and severity, send alerts to Slack or email, and link findings through a correlation graph	Apache-2.0
Wazuh	Decodes collected logs, compares events against over 3,000 built-in rules and decoders plus custom rules, writes alerts to alerts.log and alerts.json, maps alerts to MITRE ATT&CK and forwards them to the Wazuh indexer for dashboard review	GPL-2.0-only
Nextcloud admin_audit app	Logs additional event information to audit.log in the data directory or a path set with logfile_audit, giving an application-level event source to forward to the central platform	AGPL-3.0-only
OpenBao audit devices	Keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256, giving a secrets-management event source for correlation	MPL-2.0

Who owns Safeguard 13.1 and what can be outsourced

Your organization owns Safeguard 13.1. The control is an obligation on your enterprise, so accountability for centralized alerting, the decisions about what gets alerted on, and the response to what fires stays with your security function and its leadership. A partner can build the platform, but it cannot decide which risks you accept or which alerts justify waking someone at night.

Owning the control: Name an accountable owner for security event alerting, document the scope of assets feeding the platform, and keep the Coverage picture current as systems are added or retired.
Alert triage and response: Staff the queue, define severity levels, and write the escalation path from an alert to an incident ticket.
Risk decisions: Decide which log sources are in scope, how long events are retained, and which correlation alerts are acceptable as a substitute for a commercial SIEM.
Ongoing tuning: Review alert thresholds on a fixed schedule and record why rules were changed, which later supports Safeguard 13.11.
Access to the platform: Control who can change rules, silence alerts or delete logs.

Before engaging anyone, confirm that a named owner, a triage process and a tuning cadence already exist on paper.

Where centralized alerting usually falls short

Centralized alerting under Safeguard 13.1 fails in predictable places: the asset list it depends on, the sources it never receives, the rules that never fire and the alerts nobody closes. Each card below names one gap, why the CIS Controls Assessment Specification would expose it, and what to check first.

Stale asset inventory

The Coverage metric in the assessment specification compares centralized log sources against the assets you actually run, so the denominator matters. Measuring 13.1 depends on the detailed asset inventory in Safeguard 1.1 and the software inventory in Safeguard 2.1. If either list is out of date, coverage looks higher than it is because newly built hosts never appear in the count. Reconcile the SIEM source list against the inventory each month and record the differences.

Unmonitored cloud accounts

Cloud control planes, SaaS tenants and short-lived workloads often send logs to a separate account or never send them at all. A SIEM that receives on-premises servers can still report a healthy picture while a production cloud subscription is silent. Ask for a list of every cloud account, project and tenant, and confirm each one forwards audit and sign-in events to the central platform. Treat an account with no events as a finding, not as quiet.

Collection without correlation rules

Collecting logs is not the same as alerting. Safeguard 13.1 is scored as failing when there is no log correlation or log analytics tool, and a platform that only stores events gives analysts nothing to act on. Confirm that correlation or detection rules exist for authentication abuse, privilege changes, malware execution and data movement, and that each rule maps to a log type the platform actually ingests. Open-source options such as OpenSearch Security Analytics run detectors against Sigma rules and link findings through a correlation graph, but the rule set still has to be written, tested and owned.

Alerts nobody triages

An alert queue that grows faster than analysts can close it trains people to ignore it. The assessment measures centralized alerting, not whether anyone reads the results, so this gap passes an audit on paper while failing in practice. Define who owns each alert source, the severity levels that page someone, and the target for closing or escalating alerts. Keep a record of triage decisions, because that record is the proof that alerting operates.

Log sources with no integrity or retention

Central logs are only useful if they are complete and kept long enough to investigate an incident. Forwarding that drops events during outages, or that rotates out after a few days, leaves gaps an assessor will ask about. Check forwarding health with alerts on silent sources, confirm time synchronization so events correlate correctly, and document the retention period set for each log type. Application audit trails, such as the admin_audit app in Nextcloud, write to a file that must also be forwarded, not just left on the host.

No retained evidence of coverage

Assessors test 13.1 by asking for proof, not for a description of the SIEM. Without dated exports of the source list, the coverage calculation, sample alerts and triage tickets, the team has to rebuild its position under pressure. Schedule a coverage report, store it with the inventory snapshot it was calculated against, and keep sample alert records with their resolution. This evidence is what an independent assessor reviews, and DeployOpen prepares it but does not issue any assessment result.

Safeguard 13.1 questions buyers ask before hiring help

Do IG1 enterprises have to meet Safeguard 13.1?

No. Safeguard 13.1 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. CIS defines IG1 as essential cyber hygiene and a minimum standard for every enterprise, and IG1 does not require centralized alerting under this Safeguard. An IG1 organization should still confirm its own group with the CIS Controls Implementation Groups pages before scoping work, because the group determines which Safeguards the assessment applies. Organizations that have already built centralized logging may still find 13.1 useful as a model, even where it is not required for their group.

How long does centralized security event alerting take to set up?

No duration is published in the sources used for this page, so ask any partner for a timeline based on your environment. The main drivers are the number of asset classes that must send logs, how much of the enterprise asset inventory (Safeguards 1.1 and 2.1) is already accurate, whether the chosen platform is self-hosted or already deployed, the number of correlation rules to build and tune, and how many log sources need custom parsing. Organizations with a current asset inventory and an existing log pipeline typically move faster than those starting from scratch. Ask for the timeline to be written against a named list of log sources and a defined set of correlation use cases.

Do I need a SIEM to meet Safeguard 13.1?

Not necessarily. CIS describes a SIEM with vendor-defined event correlation alerts as best practice, but it also accepts a log analytics platform configured with security-relevant correlation alerts. The assessment specification scores the Safeguard on coverage, meaning the share of assets whose security logs are centralized, and it fails the Safeguard if the enterprise has no log correlation or log analytics tool at all. The practical question is whether your platform can ingest logs from your assets, correlate them, and raise alerts that someone reviews. Open-source options such as OpenSearch Security Analytics and Wazuh can cover those functions, and a partner can compare them against your log volumes and staffing.

What does the internal team need to provide during the work?

The internal team owns the controls, so it must supply the decisions and access that the partner cannot make alone. Expect to need named owners for the asset inventory and software inventory, since the assessment treats Safeguards 1.1 and 2.1 as prerequisites. You will also need access to log sources such as servers, endpoints, network devices and cloud services, a decision on which events matter for correlation, and someone who can review and act on alerts after go-live. Security operations staff should agree on alert routing to email or chat channels and on who owns escalation. Without these inputs, a centralized platform often collects logs that no one reviews.

Can we implement centralized alerting in-house without outside help?

Yes, if your team has the skills and capacity. Many organizations build this in-house with open-source tools, and nothing in the Safeguard requires an outside firm. The work usually involves platform deployment, agent or collector configuration, log parsing, detection rule development and tuning, and documenting the process for the assessment. Outside help is most often used to prepare systems and evidence on a fixed scope, to accelerate deployment, or to provide an independent view of coverage before an assessor arrives. Remember that DeployOpen prepares systems and evidence but does not issue assessment reports or certifications. Only an independent assessor or certification body does that.

What costs come with centralized alerting, and what recurs?

The costs fall into three groups: the platform itself (licensing if commercial, or infrastructure and storage if open source), the implementation work (design, deployment, parsing and rule development), and the ongoing operation (monitoring alerts, tuning, upgrades and storage growth). Implementation is largely one-time, while infrastructure, storage, support and rule tuning recur. Costs rise with the number of assets, log volume, retention periods, and the number of custom integrations. No price is given in the sources for this page, so request a breakdown from any provider that separates one-time implementation from recurring operation. Ask who pays for each line, including any third-party licensing.

What should a fixed-scope quote for Safeguard 13.1 include?

A fixed-scope quote should be tied to written deliverables before work starts. Ask for the list of in-scope assets and log sources, the chosen platform and its version, the correlation use cases to be built, the prerequisite inventories the work depends on, and the responsibilities split between your team and the partner. The quote should name the acceptance criteria, such as which log sources are centralized and which alerts are tested, and state how alert tuning will be handled after go-live. Confirm what evidence will be delivered, such as configuration records and coverage reports, and confirm that any assessment report or certification will come from an independent assessor, not from the implementation partner.

How DeployOpen scopes and prepares centralized alerting evidence

DeployOpen works on Safeguard 13.1 as an implementation partner: we prepare the centralized alerting platform and the evidence that shows it, inside your own infrastructure. The organization owns the control, and only an independent auditor or assessor issues any report or certification.

How we scope

Confirm whether Safeguard 13.1 applies, since it sits in Implementation Group 2 and above.
Record which asset inventory and software inventory outputs (Safeguards 1.1 and 2.1) will feed the alerting scope.
Agree in writing which log sources, SIEM or log analytics platform and correlation alerts are in scope.

How we build

Deploy a self-hosted platform such as OpenSearch Security Analytics or Wazuh inside your environment.
Connect log sources, configure detectors or rules, and set alert channels for the assets in scope.
Test that correlation alerts fire on representative events and that coverage of assets with centralized logs can be measured.

How we hand over

Document the architecture, log source list, coverage calculation and correlation rule inventory for assessor review.
Export the evidence an assessor would request, such as configuration records, alert samples and coverage reports.
Train your operations staff to run, review and tune the platform after the engagement closes.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Review coverage and alert quality with your team on a schedule agreed in the retainer.
Confirm with your assessor and your own environment which evidence format and retention period they accept.