10.4 Audit log review: requirements and evidence

What PCI DSS 10.4 audit log review requires and why assessors focus on it

If you must prove that log review actually happens, Requirement 10.4 is where assessors will look first. In short, it requires that logs from the cardholder data environment (CDE), critical system components and components that perform security functions are reviewed daily, that the review is carried out with automated mechanisms, that other in-scope systems are reviewed at a frequency set by a documented risk analysis, and that anything flagged is followed up. The requirement is about evidence of a working review routine, not about how much you log, so the question an assessor asks is whether a person or process looked at the right events, in time, and did something about the exceptions.

The risk behind this requirement is simple: an attacker who stays quiet inside a system leaves traces in its logs, and those traces only matter if someone reads them. Collecting logs in a central store does not complete the job. PCI SSC FAQ 1074 makes this point directly: centralized log correlation does not replace intrusion detection, and IDS/IPS logs should be part of the daily reviews. For the compliance lead, this means the review scope must explicitly include the NSCs, IDS/IPS sensors and authentication servers, not only application and database logs. Confirm this list against your own data-flow diagram before the assessor does.

Three problems make 10.4 hard in practice. The first is log sources that are never forwarded to the review platform, often a firewall added during a change or a cloud service enabled by a developer, so the daily review silently excludes them. The second is alert noise: when rules fire constantly, reviewers stop reading alerts, and an assessor will ask how noise was tuned. The third is undocumented exception handling, where analysts dismiss events in a chat thread with no record of the decision. Each of these needs a named owner, a written procedure and a retained record. Ask your team, or any outside help, to show a complete review cycle for one sample day before the assessment starts.

Which systems fall under 10.4 and which scoping decisions change the work

Requirement 10.4 does not apply the same review rule to every system. The scope group a component falls into sets its review frequency, its level of automation and how much evidence an assessor will expect. The cards below separate the groups and name the scoping decision in each that changes the effort.

Cardholder data and SAD components

Any component that stores, processes or transmits cardholder data or sensitive authentication data falls under daily review of its logs under 10.4.1. This includes payment applications, databases holding PAN and the servers that handle authorization traffic. The scoping decision that changes the work is whether a component truly holds or touches account data. Tokenization or point-to-point encryption can remove a system from this group, but only if the design is verified. Confirm the data-flow diagram matches what the logs show before you narrow the list.

Critical system components

Requirement 10.4.1 also requires daily review for all critical system components, which the entity must define in its own documented list. Common examples include directory services, key management systems and core infrastructure hosts. The decision that changes effort is how the organization defines criticality. A narrow definition shrinks daily review, but an assessor will test whether the list is justified by risk and kept current as the environment changes. Document the criteria and the owner who approves changes.

Security function components

Components that perform security functions, such as network security controls, IDS/IPS, file integrity tools and authentication servers, fall under daily review of their logs. These logs are often the first evidence of an attack, so they cannot be left to periodic checks. Under FAQ 1074, a central correlation platform does not replace intrusion detection, and IDS/IPS logs must be included in the daily review. Confirm that every security function on the diagram has its logs forwarded to the review point.

Other in-scope systems under 10.4.2

In-scope systems that are not in the daily groups, such as some inventory systems, print servers or workstations, fall under Requirement 10.4.2. Under FAQ 1304, their review frequency is set by a targeted risk analysis under 10.4.2.1, and the analysis must be documented. The decision that changes effort is how much of the estate lands here. Keeping the risk analysis specific to each system type, rather than a single blanket rule, is what an assessor usually checks first.

Out-of-scope systems and their boundary

Systems that neither store, process or transmit account data nor could affect the cardholder data environment are outside 10.4 entirely. The effort question is whether the boundary is proven. Segmentation, network tests and data-flow reviews support the claim that a system is out of scope. If a system can reach the CDE and is treated as out of scope anyway, the assessment can fail on that basis. Ask your assessor which segmentation evidence they will accept before you reduce the list.

Third-party and cloud-hosted logs

When a cloud provider, managed service or SaaS platform generates logs for in-scope systems, the entity must still review them, either directly or through a documented provider process. The decision that changes work is whether the provider exposes logs to your own review tooling or only through a portal. Confirm contract terms for log access, retention and delivery, and assign who reviews the provider's events. Responsibility matrices should name this explicitly.

How a QSA tests 10.4 and what they ask to see

This table walks through the steps an assessor follows for Requirement 10.4 and the evidence each step produces. Read it as a checklist of what to have ready before the assessment, with the common findings showing where organizations most often fall short.

Requirement	Examination steps	Evidence requested	Common findings
10.4.1 Daily review of CDE, critical and security system logs	Identify in-scope components that store, process or transmit cardholder data or SAD, critical system components, and security function components such as NSCs, IDS/IPS and authentication servers. Select review records across the assessment period and confirm each day was covered.	Log review records or dashboards for sampled days, the list of in-scope and critical components, and the reviewer's documented actions on flagged events.	Gaps on weekends or holidays, reviews that cannot be shown for sampled dates, and component lists that omit authentication servers or IDS/IPS.
10.4.1.1 Automated review mechanisms	Confirm that an automated mechanism performs the audit log reviews. Walk through the tool configuration, the rules or detectors in use, and how results reach a reviewer. Check that the mechanism was operating throughout the sampled period.	Tool configuration exports, rule or detector lists, alert routing settings, and logs showing the mechanism ran on sampled dates. Mandatory since 31 March 2025.	Manual spreadsheet reviews presented as automated, detection rules that were disabled or never tuned, and no evidence the mechanism ran before the 31 March 2025 date.
10.4.2 Review of other in-scope system logs	Identify in-scope systems not listed in 10.4.1, such as some inventory systems, print servers or workstations. Confirm each system has a review frequency that follows from the risk analysis.	Inventory of other in-scope systems, the review schedule, and records showing reviews occurred at the stated frequency.	Systems left out of the inventory entirely, or review frequencies that were set without any documented basis.
10.4.2.1 Targeted risk analysis for review frequency	Read the targeted risk analysis for documented scope, the factors considered, the rationale for each frequency, and the approval and review date. Check that the frequency in practice matches the analysis.	The signed targeted risk analysis, its supporting rationale, and evidence that the stated frequency was followed.	Risk analysis that is generic or undated, frequencies that differ from what the analysis states, and no periodic update.
Follow-up on exceptions and anomalies	Trace flagged events from the review record to the response. Confirm that exceptions were investigated and resolved by the designated personnel, and that escalations were recorded.	Tickets or case records for sampled exceptions, with timestamps, investigator names and closure notes.	Alerts closed without investigation, no record of who reviewed an event, and exceptions that stayed open without an owner.
Correlation versus intrusion detection	Check whether IDS/IPS logs are included in the daily review. Confirm that log correlation is not treated as a substitute for intrusion detection.	IDS/IPS log sources in the review scope, and sampled review records that show those logs were examined.	Correlation platform in place but IDS/IPS logs not reviewed, or intrusion detection output sent nowhere a reviewer checks.

How to implement 10.4 step by step

This sequence turns Requirement 10.4 from a policy statement into a working review routine, with each step producing a record an assessor can sample. It starts with knowing which log sources exist and ends with proof that the review ran as written.

Inventory in-scope log sources
Start with the cardholder data environment boundary and list every component that stores, processes or transmits cardholder data or sensitive authentication data, every critical system component, and every component that performs a security function such as network security controls, IDS/IPS and authentication servers. Your team owns this inventory, and it should be checked against the current scope and network diagrams. The output is a log source register that names each system, its role, its log type and whether it falls under 10.4.1 or 10.4.2. The step is done when every in-scope component appears in the register with a named owner.
Forward logs to a central platform
Route logs from every registered source to one central platform where they can be searched and reviewed together. Open-source options such as Wazuh or OpenSearch can receive logs from hosts, network devices and cloud services, but you should confirm each source type is supported before committing to a design. Protecting the stored logs is covered by Requirement 10.3, so the forwarding design should be reviewed against that page as well. The step is complete when a test event from each source appears in the central platform and the coverage gaps are recorded in the register.
Define the daily review set and risk analysis
Split the register into two groups. The first group holds the systems that require daily review under 10.4.1, including cardholder data components, critical system components and security function components such as IDS/IPS logs, which the SSC's FAQ 1074 says belong in the daily reviews. The second group holds the other in-scope systems covered by 10.4.2, where review frequency is set by a targeted risk analysis under 10.4.2.1. Document the analysis method, the reasoning for each frequency and who approved it. The output is a review scope document and a written risk analysis that an assessor can read without help from the author.
Configure automated detection and alerting
Requirement 10.4.1.1 requires automated mechanisms to perform log reviews, so build detection rules that flag suspicious or security-relevant events across the central platform. Tools such as OpenSearch Security Analytics use Sigma rules and detectors, while Wazuh compares events against its ruleset and maps alerts to MITRE ATT&CK. Tune the rules against your own environment, because default rules rarely match every application. Record which rules are active, their severity and the alert channels used. The step is done when test events trigger the expected alerts and the rule set is under version control.
Define exception triage and escalation
Write a triage procedure that explains how each alert or anomaly is classified, who investigates it, how quickly it must be handled according to your own policy, and when it is escalated to incident response. Clarify who can close an exception and what evidence closing it requires. Recognize that Requirement 10.4.3 expects exceptions and anomalies to be addressed, so the procedure must be followed in practice. The output is a triage procedure and an exception register with fields for the alert, the analyst, the decision and the closure evidence.
Run and record the review
Assign named reviewers to the daily set and to the risk-based set, and have them run the review on the schedule the documentation sets. Each review should record what was examined, what was found, what was escalated and who signed off. Keep the records in a location that is protected under Requirement 10.3. The output is a dated review log for each cycle. Confirm that a sample of reviews can be reproduced from the platform and the register, because an assessor will often ask for exactly that.
Validate the process before assessment
Before the assessor arrives, test the whole chain end to end. Generate a controlled test event on a sample of in-scope systems, confirm it reaches the central platform, triggers an alert, appears in the exception register and is closed according to procedure. Review the log source register against the current environment to catch new or retired systems. Record the results and any corrections. If you use an external consultant or a QSA, confirm their role in this validation in writing, because the organization owns the control and an independent assessor issues the conclusion. The step is complete when the test results and corrections are filed with the evidence package.

Which open-source platforms produce 10.4 evidence and how

Requirement 10.4 is met by a review process, and the review leaves records an assessor can sample. The four platforms below each produce a different kind of record: detection findings, decoded alerts, application audit trails and secrets-system request logs. Confirm in your own environment which of them can feed the review workflow you design, and remember that none of them validates PCI DSS compliance on its own.

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 is recorded as a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. A correlation graph links findings across log types, which helps a reviewer see related events from a CDE system and its firewall together. Confirm that your log sources are supported and that findings are retained long enough to show daily review. The Apache-2.0 license carries no copyleft obligation, but your team still owns configuring, patching and operating the cluster.

Wazuh decoded alerts

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. Matches are written to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques, and forwarded to the Wazuh indexer for review in the dashboard. These files give an assessor a dated, exportable trail of the review queue. Check that the rules cover the CDE, critical and security components you listed under 10.4.1, and that the review team documents how it handled each alert. Wazuh is licensed under GPL-2.0-only, so distributing modified agents or code may trigger source obligations. Take legal advice before embedding it in a product you ship.

Nextcloud admin_audit logs

The admin_audit app records additional event information to audit.log in the data directory, or to a path you set with logfile_audit. For a Nextcloud instance that stores or transmits cardholder data, this file is the application-level trail that a daily review can cover. Confirm that the events you need are captured, that the log path is protected from modification as required under 10.3, and that the file reaches your central review process rather than sitting on the application server. Nextcloud is licensed under AGPL-3.0-only, which carries network-use source obligations for modified versions. Check those obligations with counsel before you change the code.

OpenBao audit device records

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, so the record shows who requested a secret and when without exposing the secret itself. This makes it useful evidence of access to credentials that protect cardholder data. Confirm that the audit device is enabled on every cluster, that it cannot be silently disabled, and that its output is forwarded to the same review process as other logs. OpenBao is licensed under MPL-2.0, a file-level copyleft license, so changes to its own files must be shared when distributed, while your separate code is not affected.

Which evidence passes a 10.4 assessment and how to keep it current

A QSA testing Requirement 10.4 looks for proof that reviews happened, were automated where required, covered the right systems and led to action. The cards below cover the artifacts that carry that proof, and each one needs a routine so it is still accurate when the assessor arrives.

In-scope log source register

A current register listing every component that stores, processes or transmits cardholder data or sensitive authentication data, every critical system component, and every system performing security functions such as NSCs, IDS/IPS and authentication servers. Assessors compare this list against the 10.4.1 population, so a missing source is the most common gap. Keep it current by tying additions to change tickets and reconciling the register against asset inventory and log forwarding configuration each quarter. Confirm that the register also records which systems fall under 10.4.2 and why.

Automated review configuration and rule set

Evidence that automated mechanisms perform the reviews required by 10.4.1.1, which became mandatory on 31 March 2025. Export the detector, rule and alert configuration from the SIEM or log platform, and record the rule version and date each time it changes. A platform such as OpenSearch Security Analytics runs Sigma-based detectors against ingested logs, while Wazuh compares events against its ruleset. Confirm with your own tooling which exact settings an assessor will need to see.

Dated daily review records

Proof that a person or automated process reviewed logs every day, with the date, reviewer, sources covered and findings noted. Tickets, dashboard acknowledgements or signed summaries all work if they are retained and can be sampled by date. The usual failure is a gap over a weekend or holiday with no record, so check that the review workflow has a coverage rule for non-business days. Retain the records in a system with restricted write access so they cannot be edited after the fact.

Risk analysis for 10.4.2 systems

The documented, targeted risk analysis that sets the review frequency for in-scope systems not listed in 10.4.1, such as some inventory systems, print servers or workstations. FAQ 1304 confirms that these systems fall under 10.4.2, and the analysis must justify why the chosen frequency is adequate. Refresh the analysis when the system's role, data exposure or threat profile changes, and record the date of each review. Confirm the method your assessor accepts before you write it.

Exception and follow-up records

Tickets that show each anomaly from log review was triaged, investigated and closed with a stated outcome. Assessors sample these to confirm that review produces action, so a log of alerts with no disposition is weak evidence. Link each ticket to the originating alert and the affected log source. Also keep records for IDS/IPS events, since FAQ 1074 states that correlation does not replace intrusion detection and those logs belong in daily review.

Written review procedure

A procedure that states who reviews which sources, how often, which tools they use, how exceptions escalate and how reviewers handle absence or staff turnover. It should match what staff actually do, because assessors compare the document with interviews and sampled records. Assign an owner, review the procedure at least annually and after any change to the logging platform, and keep prior versions with dates. Confirm that roles here align with the documented responsibilities under 10.1.

What meeting 10.4 costs in money and effort

This table breaks down the cost and effort components of meeting Requirement 10.4 audit log review, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No prices or durations were available, so use the drivers and the quote checklist to compare offers on the same scope.

Cost component	One-time or recurring	What drives it up	What keeps it down
Tooling or licenses	Recurring	Commercial SIEM pricing tied to log volume, number of event sources, and add-on modules	Open-source platforms such as OpenSearch Security Analytics or Wazuh remove license spend, though hosting and storage remain
Engineering time to forward logs and tune detections	One-time, with later changes	Many heterogeneous sources, unparsed log formats, and custom detection rules written from scratch	Standardized log forwarding, a defined in-scope source inventory, and reuse of prepackaged detection rules
Daily review effort for 10.4.1 sources	Recurring	Large CDE footprint, high alert volume, unclear triage ownership, and weak correlation	Tuned detections, documented triage steps, automated alert routing, and clear escalation thresholds
Risk-based review for 10.4.2 systems	Recurring, set by the targeted risk analysis	Broad system inclusion and review frequencies set higher than the risk supports	A documented targeted risk analysis that justifies frequency and scope per system class
Evidence upkeep	Recurring	Manual screenshots, unversioned review records, and scattered tickets	Automated review records retained in one place, with each exception linked to its follow-up
Exception follow-up and investigation	Recurring, variable	Frequent false positives, slow response paths, and missing runbooks	Tuned rules, defined severity levels, and tested response procedures
External testing or review	Recurring or per engagement	Scope breadth, number of in-scope systems, and whether a consultant or ASV is engaged	Written scope, independent assessor and consultant roles kept separate, and prepared evidence before fieldwork
QSA sampling time	Recurring at each assessment	Number of log sources sampled, gaps in evidence, and reviews that lack traceable follow-up	Consistent review records and a sample-ready evidence set for the assessor

Who does what for 10.4: your team, a partner and the assessor

Your organization owns Requirement 10.4 in full. The review must be performed, recorded and acted on by people you employ or formally contract, and the accountability for exception decisions stays with you even when tooling does most of the filtering. Assessors will ask who reviews the logs each day, how that person was trained, and who signs off when an alert is dismissed.

Daily review ownership: Name the roles that review logs from CDE components, critical system components and security functions, and document backup coverage for absences.
Sign-off and evidence: Record each review with a reviewer, a date and the outcome, so the review itself can be sampled later.
Exception decisions: Decide and document why an alert is closed, escalated or converted into an incident, and keep the follow-up tied to a ticket.
Risk-based frequency: Own the targeted risk analysis that sets review frequency for in-scope systems outside 10.4.1.
Tuning and rule changes: Approve changes to detection rules and suppressions, since a silenced rule without approval is a common finding.

Before engaging anyone, confirm which of these roles already exist in your organization and who signs the 10.4 procedure.

Where 10.4 programs usually fall short and how to close the gap

Most Requirement 10.4 findings come from a handful of predictable gaps: sources that never reach the central platform, reviews that stay manual, and records that cannot prove who looked at what. Each card names one gap, why an assessor will notice it, and the closing action that addresses it.

Log sources never forwarded centrally

A review cannot cover logs that never leave the host. Database servers, jump hosts, and cloud control planes often keep logs locally or send them to a tool no one watches. Before the assessment, build a list of every in-scope component under 10.4.1 and 10.4.2 and confirm each one forwards to the central platform. Then check that a test event from each source appears in the index. Forwarding agents on hosts are often the first thing to fail silently after patching, so monitor the forwarder itself.

Manual review where automation is required

Requirement 10.4.1.1 requires automated mechanisms for audit log review, and that expectation became mandatory on 31 March 2025. A team that scrolls through logs each morning or exports CSV files to a spreadsheet will struggle to show the automation the assessor expects. Configure detectors or rule sets that generate findings from the in-scope logs, route them to a queue, and keep the rule configuration under change control. Manual review can still supplement the automation, but it should not be the mechanism of record.

No risk analysis for 10.4.2 systems

Systems outside 10.4.1, such as print servers, some inventory systems, and workstations, still need log review, but the frequency must come from a documented targeted risk analysis under 10.4.2.1. Many programs either review these systems daily by default or never review them at all, and neither approach has a documented rationale. Build an inventory of these systems, record the risk factors that set each review frequency, and get the analysis approved by the people who own the risk. Revisit it when the environment changes.

IDS/IPS logs excluded from daily review

Teams often treat correlation as a substitute for intrusion detection, so IDS and IPS logs drop out of the daily routine. PCI SSC FAQ 1074 is clear that centralized log correlation does not replace intrusion detection, and that IDS/IPS logs should be part of the daily log reviews. Add the sensor logs to the in-scope sources, confirm alerts from them reach the review queue, and include them in the daily review evidence. A sensor that generates alerts no one sees does not meet the requirement.

Review records lacking reviewer and time

An assessor will ask who reviewed what, when, and what they decided. A ticket that says reviewed or a shared checkbox does not show that. Set up review records that capture the reviewer's identity, the log sources covered, the time window, the findings examined, and the disposition of each. Where automation generates the review, keep the rule version and the alert history so the record can be reproduced. Confirm with your assessor which record format they accept before the period begins.

Exceptions closed without follow-up

A finding that is acknowledged and closed without an investigation or a recorded reason is a common failure. Assessors look for the path from an exception to a documented outcome: the investigation, the escalation under the incident process, and the closure rationale. Define severity thresholds, assign an owner for each exception queue, and set a rule that no exception closes without a note explaining the outcome. Sample a set of closed exceptions each month to confirm the follow-up actually happened.

Questions buyers ask about 10.4 cost, effort and outside help

How much effort does requirement 10.4 take, and what drives it?

The effort depends mostly on how many systems are in scope, how many log sources they produce, and whether review already runs through automated tooling. Requirement 10.4.1 sets a daily review for the cardholder data environment, critical system components and components that perform security functions such as network security controls, IDS/IPS and authentication servers. Requirement 10.4.1.1 requires those reviews to use automated mechanisms, so the one-time build of collection, detection rules and alert routing is usually the largest item. After that, the recurring cost is staff time to triage alerts, document reviews and work exceptions. Ask any provider to estimate effort by log source and by review type, not as one lump sum.

Can a team meet 10.4 without outside help?

Yes, a team with security operations skills and clear ownership can meet 10.4 without an outside implementer, because the standard describes outcomes and does not prescribe a product. The harder part is proving that reviews happen on schedule and that exceptions get followed up, which needs consistent records over the whole assessment period. Teams that lack a SIEM or detection engineering experience often find the rule tuning and alert triage take longer than expected. An outside partner can help build and document the pipeline, but the organization still owns the review process and its results.

How long does preparation for 10.4 usually take, and what does it depend on?

No supplied figure sets a standard duration, so treat any timeline as something to confirm in writing. Preparation depends on the number of log sources, whether a central log platform already exists, how mature the detection rules are, and whether the existing review is manual. Work usually splits into scoping the systems that fall under 10.4.1 and 10.4.2, building automated collection and alerting, defining review procedures, and running the process long enough to produce history for the assessor. Ask a provider to show dependencies, the systems each phase covers, and which steps need your change windows or access approvals.

What does the work need from our internal staff?

Internal staff need to own the decisions that define the review: which systems are critical, which logs count as security function logs, who reviews what, and what counts as an exception that needs follow-up. Someone must also approve detection rules, confirm alert destinations and keep the review records. Engineers provide access to log sources and network segments, and the security team reviews alert quality after go-live. If those roles are not named before work starts, the review tends to stall or produce evidence that the assessor will question.

Can our implementation partner also act as our QSA for 10.4?

No. An implementation partner prepares systems, configures tooling and produces evidence, while only a Qualified Security Assessor (QSA) can assess the environment and issue a Report on Compliance. Using the same firm to build the controls and to judge them creates an independence conflict that most organizations want to avoid. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications. Confirm your assessor's independence rules before engaging anyone, and keep the implementation scope and the assessment scope in separate written agreements.

Are open-source tools acceptable for 10.4 log review?

The standard does not require a commercial product, so open-source tools can meet 10.4 when they perform the required automated review and produce reliable evidence. Platforms such as Wazuh, which matches events against a large built-in ruleset and writes alerts to files and an indexer, and OpenSearch Security Analytics, which runs detectors built from Sigma rules, are commonly evaluated for this purpose. Confirm with your assessor that the tool, its rules and its outputs cover every in-scope log source, and document how the tool was configured and tested. Note that centralized correlation does not replace intrusion detection, so IDS/IPS logs should still be part of the daily reviews.

What should we ask for in a written quote for 10.4 work?

A useful quote lists the systems and log sources in scope, the review tasks for each requirement (10.4.1, 10.4.1.1 and 10.4.2), and the deliverables such as configuration records, detection rule sets, runbooks and evidence packages. It should separate one-time build work from recurring work such as rule tuning, upgrades and ongoing support, which may be offered as a retainer. Ask who performs each task, what your staff must provide, what is excluded, and how changes to scope are priced. Because DeployOpen works from a written scope and does not publish a price list, the quote follows from that scope and is the document to compare across providers.

How DeployOpen scopes, implements and prepares 10.4 evidence

DeployOpen works on 10.4 as a fixed-scope engagement inside your own infrastructure. We agree which log sources feed the review, build the automated review mechanisms on self-hosted open-source platforms, and document the evidence an assessor will ask for. Your organization owns the review process and its outcomes, and an independent QSA or assessor tests the result.

How we scope

Inventory every log source that falls under 10.4.1, including CDE components, critical systems and security functions such as NSCs and IDS/IPS.
Identify in-scope systems under 10.4.2 and agree the targeted risk analysis that sets their review frequency.
Record the scope, deliverables and timelines in writing before any implementation work begins.

How we build

Configure automated log review on self-hosted platforms such as OpenSearch Security Analytics or Wazuh, inside your accounts or data centers.
Write and tune detection rules so IDS/IPS and security control events appear in the daily review queue.
Test that alerts reach the right reviewers and that matches are recorded as findings with rule, log type and severity.

How we hand over

Document the review procedure, roles, escalation paths and how each exception is followed up and closed.
Deliver evidence samples showing daily reviews, automated mechanism configuration and findings resolution for your assessor.
Train your reviewers on the dashboards and alert triage so the process runs without our involvement.

How we support

Agree a retainer for ongoing rule updates, platform upgrades and review of alert volume and tuning.
Re-check the review mechanisms after environment changes, such as new CDE components or cloud services.
Confirm with your QSA or assessor which evidence formats they accept before the assessment window opens.