What 03.03.05 asks for and why assessors focus on it
Requirement 03.03.05 asks the organization to review and analyze its system audit records at a defined frequency, look for indications of inappropriate or unusual activity, report what it finds to designated personnel or roles, and correlate audit records across repositories so the organization has a shared picture of what is happening. If a contract requires NIST SP 800-171 and your systems already write logs, this is the requirement that asks whether anyone reads them. Logging under 03.03.01 through 03.03.03 produces raw material. 03.03.05 is where that material becomes a decision, a report or an escalation.
The requirement has one organization-defined parameter: the frequency of review and analysis. NIST does not set that value, so your organization must choose it and write it down in the system security plan and audit procedures. Assessors check that the value is defined, then check that reviews happen at that frequency. Expect them to ask for the reviewers' names, the findings reports and the records of actions taken in response. An interview with the people who carry these duties is part of the test, so confirm that the reviewers can explain what they look for and who receives their findings. Rev. 2 requirement 3.3.5 maps to this requirement, and NIST's change analysis classifies that change as significant, with more detail and foundational tasks than the Rev. 2 wording. Confirm the Rev. 3 expectations against NIST's change analysis before you reuse older Rev. 2 evidence.
Assessors focus here because it is where the logging program either works or stops. CMMC Level 2 still assesses the Rev. 2 version as AU.L2-3.3.5, worth 5 points under the 32 CFR 170.24 scoring methodology, and 32 CFR 170.21 does not allow it on a plan of action and milestones for Conditional status. A security information and event management or log analytics tool, such as OpenSearch Security Analytics or Wazuh, can produce alerts and correlate events, but the tool only satisfies this requirement when a named role reviews its output on schedule and records the outcome. Ask your auditor which evidence format they expect, and document the review cadence before the assessment begins.
Which systems, logs and teams fall under 03.03.05 review
Under 03.03.05, the review scope follows the CUI boundary, not the size of the log estate. Each card below names a decision that changes who reviews which records, how often, and what evidence an assessor will ask to see. Confirm each one in writing before the review schedule is set.
Systems inside the CUI boundary
Every system that stores, processes or transmits CUI, plus the security tools that protect it, produces audit records that fall under the review. Start from the system security plan boundary and list each host, database, application and network device. Check whether domain controllers, hypervisors and backup servers are included, because they often hold authentication or CUI data and are easy to leave out of the review schedule. Ask the assessor to confirm the boundary before you set the review frequency.
SaaS and cloud audit logs
Audit logs from email, collaboration suites, identity providers and cloud consoles may sit outside your infrastructure but still record access to CUI. Decide whether each service is in scope, and if it is, confirm that you can export or query its logs at the frequency you define. Check the retention and export limits of each provider, and record which party is responsible for reviewing the logs. A provider's log portal does not count as a review unless someone performs and records the review.
Repositories that must be correlated
03.03.05 requires analysis and correlation of audit records across repositories, so identity logs, endpoint logs, network logs and application logs need a common view. Identify each repository, its format and its time source, and decide which one is the system of record for each event type. Records with mismatched clocks or missing identifiers cannot be correlated, so verify this against your logging design before the first review cycle.
Third-party services that hold logs
Managed security providers, outsourced SOC services and cloud logging platforms may collect and store your audit records. Their contracts should state what they collect, where the records are stored, who can access them and how you receive findings. Confirm that the provider's review output reaches your designated roles within the timeframe you have defined, and that you keep a copy of the records you rely on for an assessment.
Roles that receive findings
03.03.05 requires findings to be reported to organizational personnel or roles, so name the people who receive each category of alert, such as a security operations lead, a system owner or a compliance lead. Document the escalation path for suspicious activity and the record of actions taken in response. Interviews during an assessment test whether these roles know their duties, so confirm that the named people can explain them.
Scoping decisions that change the work
Several choices alter the review effort: whether shared or multi-tenant platforms are in scope, whether test and development environments that touch CUI are included, and whether the review is performed by staff, a provider or a combination. Each choice changes the number of repositories, the number of roles and the evidence you must keep. Record these decisions in the system security plan and agree them with your assessing body before you rely on them.
How an assessor tests audit record review under SP 800-171A
An assessor testing 03.03.05 checks four determination statements and one parameter check, using the examine, interview and test methods described in SP 800-171A Rev. 3. The determination statements cover whether the organization reviews and analyzes audit records at the frequency it defined, whether it looks for indications and potential impact of inappropriate or unusual activity, whether it reports findings to the right personnel or roles, and whether it analyzes and correlates records across repositories. The ODP check asks whether the organization has actually defined that review frequency. An assessor will not accept a policy that says "regularly" in place of a number, so the first task is to confirm the frequency is written down and matches what staff do. Expect the assessor to compare the stated frequency against the dates on review records.
Examine objects are the documents and records the assessor reads. For this requirement they typically include the audit and accountability policy and procedures, the written procedure for audit record review, analysis and reporting, reports of findings, and records showing what was done in response to each review. Interview objects are the people who run the reviews and the people with information security responsibility. The assessor will ask a reviewer to walk through a recent review, explain how an unusual event was escalated and confirm who receives reports. Test objects are the mechanisms that support analysis and correlation, such as a SIEM, log analytics platform or detection rules. The assessor may ask you to run a search across two log sources and show that events from both can be connected. Confirm, before the assessment, that each of these objects exists and can be produced on request.
What assessors ask for, by method
The examine method is where assessors read documents and records to confirm that review and analysis of audit records is defined, planned and actually carried out. For 03.03.05, the objects include the audit and accountability policy, the procedures for audit record review, analysis and reporting, reports of audit record findings, and records of actions taken in response to those reviews. An assessor will expect the documents to match what happens in the system, so a procedure that names a review cadence should be backed by dated review records.
- Review procedure: A written procedure that names who reviews, which logs they review, the review frequency your organization has defined for this requirement, and how a reviewer escalates a finding.
- Findings reports: Dated reports or tickets showing what was reviewed, what was found, and whether the finding was judged benign or unusual.
- Records of actions taken: Tickets, incident records or case notes that show follow-up on each finding, including closure and the reason for closure.
- Frequency evidence: Calendar entries, review logs or dashboard history showing the defined frequency was met over the assessment period.
Before the assessment, check that the procedure, the review records and the action records tell the same story for the same period.
The interview method tests whether the people responsible for audit record review know their role, understand the procedure and can explain how they respond to unusual activity. Assessors interview personnel with audit review, analysis and reporting responsibilities, and personnel with information security responsibilities more broadly. The goal is to confirm that the written procedure is the working practice, not a document no one has read.
- Review ownership: Who reviews the logs, who backs them up when they are unavailable, and who receives the findings.
- Escalation path: What a reviewer does when a pattern looks like inappropriate or unusual activity, and who decides whether it becomes an incident.
- Frequency in practice: How the reviewer knows the review is due, and what happens when a review is missed.
- Reporting to others: How findings reach system owners, management or the incident response team, and in what form.
Brief the reviewers and security leads beforehand so each can answer these questions consistently with the written procedure.
The test method checks that the technical mechanisms actually support analysis and correlation of audit records. For 03.03.05, the test objects are the mechanisms that support analyzing and correlating audit records across repositories. An assessor may ask you to show a detection rule firing on test data, a correlation view that links events from different sources, or a dashboard that reviewers use. The mechanism should work on the organization's real log sources, not only on a demo dataset.
- Analysis tooling: A SIEM or detection platform that ingests logs from hosts, network devices, cloud services and applications, with rules that flag unusual activity.
- Correlation across repositories: Evidence that events from separate log stores can be linked, for example one user's activity across an identity provider, a file service and an application.
- Live demonstration: A controlled test event, such as a failed login burst, that the assessor can watch raise a finding and reach a reviewer.
- Configuration evidence: Exported rule sets, detector settings and alert routing configuration that show what is monitored and where alerts go.
Confirm with your platform documentation exactly which correlation and alerting features your version provides, and test them before the assessor arrives.
Assessment evidence for 03.03.05 is only as good as the logs behind it. Open-source platforms can produce much of the analysis evidence, but each one covers different sources and features. Wazuh, for example, decodes logs and matches events against a large built-in ruleset, writing alerts to local files and forwarding them for dashboard review. OpenSearch Security Analytics runs detectors against ingested logs using Sigma rules and links findings through a correlation graph. Application-level sources such as Nextcloud's admin_audit app write to a separate audit file, which must also be collected and reviewed.
- Wazuh alert output: Alerts written to alerts.log and alerts.json, plus dashboard records of who reviewed them.
- OpenSearch findings: Detector findings recording rule, log type and severity, with alert channels such as Slack or email.
- Application audit logs: Nextcloud audit entries in audit.log, or the path set with logfile_audit, collected into the central review.
- Secrets platform logs: OpenBao audit device output, which records API requests and responses with sensitive values hashed.
Map each source your assessor will see to a named reviewer and a review record, and confirm each collection path with your platform team.
Implementing 03.03.05 in the order that passes assessment
This sequence turns 03.03.05 from a policy statement into a working review cycle that an assessor can examine, interview staff about and test. Each step produces a record that the next step depends on, so the evidence trail builds as the work progresses.
Set and document the review frequency
The organization defines how often system audit records are reviewed and analyzed, because 03.03.05 leaves that frequency as an organization-defined parameter (ODP) that NIST does not fill in for you. Document the chosen value in the audit and accountability procedures and in the system security plan, and tie it to the systems in scope. The step is done when an assessor can read one value and find it in both documents. Confirm with your contract or agreement owner whether a federal agency has specified a value, since that would override your choice.
Name reviewers and report recipients
Assign who performs the reviews, who receives findings and who can act on them, and record the roles rather than only individual names so coverage survives staff changes. Include personnel with information security responsibilities as recipients of significant findings. The output is a written assignment with backups for each role and a short description of each person's duties. Assessors interview these people, so each one should be able to explain what they review and how they report it.
Define what counts as inappropriate or unusual activity
Write the criteria reviewers use to decide that a record needs attention, such as repeated failed logons, administrative changes outside change windows, or access to CUI repositories by unexpected accounts. Link these criteria to the event types selected under 03.03.01 so the review covers what the system actually logs. The output is a reviewer-facing rule set with a version and owner. Keep it short enough that a reviewer can apply it during a shift.
Configure detection and correlation across repositories
Load the criteria into the detection tooling and connect the log sources that hold CUI-related records, including hosts, network devices, cloud services and applications. Open-source options such as OpenSearch Security Analytics (Apache-2.0) can run detectors against Sigma rules and link findings across log types, and Wazuh (GPL-2.0-only) can match events against its ruleset and forward alerts for review. Confirm each platform's current log-type coverage against your own environment before you rely on it. The step is done when a test event from each source produces a visible finding in the review queue.
Run reviews on schedule and record the results
Perform the reviews at the frequency set in step one, working through the queue of findings and any unreviewed alerts. Record each review with the date, the reviewer, the records examined, the findings and the disposition of each finding, including reviews where nothing was found. A review with no record is indistinguishable from a missed review during assessment, so the log of reviews is itself evidence. Check that alerts reached their recipients, since delivery gaps are a common reason reviews are skipped.
Report findings to the defined recipients
Send each finding that meets the reporting criteria to the roles set in step two, through the channel the organization documented, such as a ticket queue, email or a chat channel. Include enough context for the recipient to act without reopening the raw logs. The output is a report record per finding that shows who received it and when. Reports made by a platform's alert channel count only if the record shows the human recipient received and acknowledged them.
Close the loop on actions taken
Track each finding to a documented outcome, such as an investigation, a containment action, a configuration change, a closed false positive or an incident record under 03.06. Link the action to the review record so an assessor can follow a finding from detection through response. Periodically check that the criteria in step three still match what the reviews find, and update the rules and the documented frequency when they do not. The step is complete when a sample of findings can each be traced from alert to recorded action.
Evidence that passes 03.03.05 and how to keep it current
An assessor testing 03.03.05 looks for a defined review frequency, proof that reviews happened on schedule, findings that were reported, and actions that followed. The cards below cover each artifact and the configuration that generates them, so evidence accumulates during normal operations rather than being rebuilt before each assessment.
Written review procedure
The assessor will first look for the procedure that tells analysts what to review, which sources are in scope, what counts as inappropriate or unusual activity, and who receives findings. Confirm that the procedure names the review frequency your organization defined for the ODP, and that the procedure matches what the team actually does. A procedure that describes a daily review while the logs show weekly activity is a finding in its own right.
Review records with dates and reviewers
Each review should leave a record showing when it happened, which audit sources were covered, who performed it, and what was found or that nothing was found. A quiet period still needs a record. Keep these entries in a ticketing or case system with fixed fields so an assessor can sample any date in the window and see the review behind it.
Findings reports to designated roles
The requirement asks that findings reach organizational personnel or roles. Evidence is the report itself, the distribution list or role that received it, and the timestamp of delivery. Alerts from a SIEM or log platform can serve as the findings record if they carry the rule, log type, severity and destination, but confirm that the recipients listed in your plan are the ones who actually receive them.
Records of actions taken
Assessors test whether a finding led to a response. Link each finding to its triage decision, investigation notes, containment steps, and closure or escalation to incident response under 03.06. A finding closed with no reasoning, or a suspicious event with no record of follow-up, weakens the evidence even when detection worked.
Correlation rule and detector configuration
The requirement covers analysis and correlation across repositories, so keep exports of the detector and correlation configuration with change history. Show which log types feed each detector, which Sigma or custom rules are active, and how findings link across sources. Exporting these settings on a schedule gives you dated proof of the configuration that was in force during any review period.
Keeping evidence current between assessments
Automate the outputs that prove the control: scheduled report exports, alert delivery logs, and retained review tickets, all written to protected storage under 03.03.08. Run a periodic sample check, pulling a random date and confirming the review, findings and follow-up are all present. Gaps found in the sample are cheaper to fix in the month they occur than during an assessment.
What meeting 03.03.05 costs in money and effort
This table lists the cost components of meeting 03.03.05, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No dollar figures are supplied for this requirement, so use the rows to build a quote request and to decide which parts to keep in house. The main takeaway is that the review cadence and the number of log sources drive most of the recurring effort.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Detection tooling or licenses | Software vendor for commercial SIEM, or no license fee for self-hosted open source such as OpenSearch Security Analytics or Wazuh | Commercial licenses recur, typically annually; open-source licenses carry no license fee | Log volume and number of sources; open-source removes license spend but not hosting or staffing |
| Hosting and storage for the analytics platform | Cloud or data center provider, or internal infrastructure team | Recurring | Retention period set by the records retention policy, and the volume of ingested logs from hosts, network devices and cloud services |
| Engineering time to define the review frequency and detection rules | Internal platform or security engineers, or an implementation partner under a written scope | One-time, with periodic updates | Number of log types, custom Sigma or Wazuh rules needed, and how many systems fall under the CUI boundary |
| Correlation and cross-repository setup | Internal engineers or implementation partner | One-time build, recurring tuning | Number of repositories holding audit records (for example, Nextcloud audit.log or OpenBao audit devices) and whether time stamps are consistent across them |
| Recurring reviewer time for analysis and reporting | Internal security operations staff assigned to the defined review frequency | Recurring | Alert volume, the review frequency the organization sets as its ODP value, and how much tuning reduces false positives |
| Evidence upkeep | Internal compliance or security staff | Recurring | Retention of review reports, records of actions taken and findings sent to personnel, which the assessment procedure examines |
| External review or testing | Independent testing firm or implementation partner, under a fixed scope | Optional, usually periodic | Whether the organization wants an outside check of the detection logic before a federal agency or assessor reviews it |
| Assessor sampling and assessment fees | Assessor or DCMA DIBCAC, depending on the assessment type in the contract | One-time per assessment cycle | Number of systems in scope, how many review records the assessor samples, and how well evidence is already organized |
Who owns review, who prepares evidence, and who assesses
The organization that holds the contract or handles CUI owns 03.03.05 in full. Someone on its staff must decide how often audit records are reviewed (the one organization-defined parameter for this requirement), act on what the review finds, and be able to show that the review happened. A partner can build the detection pipeline, but it cannot decide what counts as unusual activity for your users, your data or your contracts.
- Setting the review frequency: Write the defined frequency into the audit and accountability procedures and record why that frequency fits the system's risk.
- Assigning reviewers and backups: Name the roles that review findings and the people who cover when they are absent.
- Deciding triage and escalation: Define what gets reported, to whom, and what action each severity triggers.
- Keeping action records: Log what was done in response to each review, since assessors look for records of actions taken.
- Signing off on exceptions: Accept or reject tuning decisions that suppress alerts.
Check that your staff can name the reviewers, the frequency and the escalation path without consulting the partner.
An implementation partner such as DeployOpen prepares the systems and evidence that support 03.03.05. Work typically covers deploying the log analysis platform inside your environment, connecting log sources, setting up detection content, and packaging the outputs an assessor will examine. The partner does not review your logs on your behalf unless you contract that as a managed service, and it does not issue any assessment result.
- Detection tuning: Adjust rules and detectors so that findings reflect your environment, and document each change and its reason.
- Correlation setup: Configure how findings from different repositories are linked, so reviewers see organization-wide patterns.
- Evidence packaging: Collect dashboards, alert records, review reports and tuning history into a form that maps to the examine and test objects in SP 800-171A.
- Reporting workflow: Build the path that routes findings to the named roles and records their resolution.
- Documentation handover: Deliver runbooks that your staff can operate after the engagement ends.
Ask for the scope of tuning and correlation work in writing, and confirm whether ongoing retainer support is included.
Only an independent assessor issues the assessment result for 03.03.05. Depending on the assessment type, that is a qualified third party or the Government's assessment body. The assessor tests the requirement against the determination statements in SP 800-171A Rev. 3 using the examine, interview and test methods. It is the assessor's conclusion, not the partner's readiness work, that determines whether the requirement is met.
- Examining artifacts: Reviewing the audit and accountability policy, review procedures, findings reports and records of actions taken.
- Interviewing personnel: Confirming that reviewers and information security staff know their responsibilities and perform them.
- Testing mechanisms: Observing the analysis and correlation tooling operate on sample records.
- Checking the ODP: Confirming the review frequency is defined and followed.
- Reporting results: Documenting findings the assessor has verified, which the organization then uses in its records.
Confirm the assessor's qualifications and assessment scope before engaging them, and keep the partner and assessor engagements separate so that independence is preserved.
Where 03.03.05 evidence usually breaks down
Assessors test 03.03.05 by asking for proof that someone reviewed audit records on a schedule, acted on what they found and reported it to the right roles. The gaps below tend to appear in that chain, and each one is easier to fix before an assessment than during it.
No defined review frequency
The requirement leaves the review frequency as an organization-defined parameter, so the organization has to assign the value. Many systems have logs turned on but no written cadence, which leaves an assessor with nothing to measure reviews against. Closing step: record the frequency in the audit and accountability policy and the system security plan, and confirm the value matches what the review logs actually show.
Reviews with no record
Staff may review logs daily, but if nothing is written down, the review cannot be shown. Assessors look for reports of audit record findings and records of actions taken after each review. Closing step: keep a dated review log that names the reviewer, the sources checked, the time range and the result, even when the result is no findings.
Findings not reported to roles
Analysis that stays with one administrator does not meet the requirement to report findings to defined personnel or roles. Reports often go to a shared inbox or a chat channel with no owner and no record of who received them. Closing step: name the roles that receive reports, define the report contents, and keep proof of delivery for each report.
No correlation across repositories
Authentication logs in one system, firewall events in another and application audit trails in a third can each look normal alone. The requirement expects analysis and correlation across repositories for organization-wide awareness. Closing step: confirm which repositories feed a central analysis point, and test that a sample event can be traced across at least two of them.
Actions not tied to findings
A review that surfaces a suspicious login should lead to a documented response, such as a ticket, a containment step or a closed-as-benign note. When tickets exist but do not reference the audit record that triggered them, the chain is broken. Closing step: require every finding to carry a ticket or case identifier, and link each closed case back to the record ID that raised it.
Questions buyers ask about 03.03.05
What drives the cost of meeting 03.03.05 audit record review?
The cost depends mostly on how many systems produce audit records, how many log repositories must be correlated, and how much review work the organization can absorb in-house. No figure for this requirement was supplied, so ask any partner for a written quote built from your scope rather than a rate card. Costs fall into one-time items (designing review procedures, configuring detection rules, building dashboards and writing the review records) and recurring items (staff time for review, rule tuning, and periodic evidence collection). Ask each bidder to separate those two groups and to state which items are paid to the partner, which are paid to licensed tooling, and which fall on your own staff.
How long does it take to implement 03.03.05 review and correlation?
No duration was supplied for this requirement, so treat any timeline as something to confirm in writing. The schedule depends on whether log sources already reach a central store, how many event types have been defined under 03.03.01, and whether the review frequency has already been set as an organization-defined parameter. Ask for the implementation steps, the dependencies on other audit requirements such as 03.03.02, 03.03.03 and 03.03.06, and the point at which the review process produces its first recorded review. Fixed-scope engagements agree deliverables and timing before work begins.
What does our staff need to provide for this work?
The work needs named people who own the review process, usually from security operations or the information security team, plus access to log sources, the current audit and accountability policy, and an agreed incident escalation path. An assessor will interview people with audit review responsibilities, so those people must be able to explain how they review logs and what they do with findings. Expect to supply subject-matter time for defining what counts as unusual activity in your environment and for approving the review frequency. Confirm these commitments in the statement of work so that staff time is planned rather than assumed.
Can our own team handle 03.03.05 without an outside partner?
Yes, an in-house team can meet 03.03.05 if it has people who understand the logging platform, the systems in scope and the assessment method. The requirement itself is about process: defined review frequency, documented analysis, reported findings and correlation across repositories. The usual gap is evidence, because the review must be shown as having happened on schedule, with records of findings and actions taken. A partner is most useful when the team lacks detection engineering experience or needs help preparing the assessment package. Whichever route you choose, the organization owns the control, and only an independent assessor can issue an assessment result.
What does an implementation partner handle, and what stays with us?
An implementation partner such as DeployOpen can plan, configure, integrate and document the review capability on self-hosted open-source platforms inside your infrastructure, and prepare the evidence an assessor will examine. Your organization keeps ownership of the control, sets the review frequency and defined events of interest, decides how findings are escalated, and signs off on the policy. The partner does not issue assessment results or certifications. Ask the partner to state in writing which deliverables it produces, such as rule configuration, correlation setup, review runbooks and evidence exports, and which decisions remain with your staff.
How does Rev. 2 differ from Rev. 3 for 03.03.05?
In Rev. 3 the requirement is numbered 03.03.05 and traces to Rev. 2 requirement 3.3.5. NIST's change analysis classifies the change as significant, because Rev. 3 asks for more detail and adds foundational tasks. Rev. 3 also defines one organization-defined parameter for this requirement, the frequency of review and analysis, which your organization must assign if a federal agency does not specify it. Contracts may still reference Rev. 2 numbering, and CMMC Level 2 assesses the Rev. 2 requirement as AU.L2-3.3.5, worth 5 points under the 32 CFR 170.24 scoring methodology. That point value also means it cannot be placed on a POA&M for Conditional status under 32 CFR 170.21, so confirm which revision your contract cites before planning evidence.
Which open-source tools produce the evidence for 03.03.05?
Several self-hosted platforms can support the review and correlation work, but none satisfies the requirement by installation alone. OpenSearch Security Analytics runs detectors against ingested logs using Sigma rules, records matches as findings and links findings across log types in a correlation graph. Wazuh decodes logs, compares events against its ruleset and writes alerts to alerts.json for review in its dashboard. Nextcloud's admin_audit app writes to audit.log, and OpenBao audit devices keep a JSON log of API requests. Confirm each platform's current capabilities and licensing with its documentation before selecting it, and document how your review frequency and escalation steps use the output.
What evidence will an assessor ask to see for 03.03.05?
An assessor using SP 800-171A examines audit and accountability policy, the procedures for audit record review, analysis and reporting, reports of findings, and records of actions taken in response. Interviews cover personnel who perform reviews and information security staff. Tests cover the mechanisms that support analysis and correlation. In practice this means keeping a defined review schedule, dated review records showing who reviewed what, alert and finding reports with their disposition, and configuration exports showing correlation is active. Assemble these before the assessment rather than reconstructing them during it.
How DeployOpen prepares 03.03.05 review evidence
DeployOpen plans, implements and documents the audit record review workflow for 03.03.05 inside the client's own infrastructure, using self-hosted open-source platforms. The organization owns the review decisions and its controls, while an independent assessor makes the judgment on compliance.
How we scope
- Agree in writing which log sources, repositories and review roles fall under 03.03.05 before work starts.
- Confirm with the client the review frequency it will define as the organization-defined parameter for 03.03.05.
- Identify which assessment objects the client expects to show, such as review procedures, findings reports and records of actions taken.
How we build
- Configure a log analysis platform such as Wazuh or OpenSearch Security Analytics to flag inappropriate or unusual activity from ingested logs.
- Set up detection rules and alert routing so findings reach the personnel or roles the client has named for review.
- Connect audit sources such as Nextcloud audit logs and OpenBao audit devices into one correlation view across repositories.
How we hand over
- Document the review procedure, the defined frequency and the reporting path so an assessor can examine them directly.
- Deliver sample findings records and tickets showing how review results and response actions were logged and retained.
- Provide a walkthrough so the client's staff can run reviews and explain the workflow during interviews.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is delivered.
- Revisit detection rules and correlation logic when the client changes log sources or its review frequency.
- Ask your assessor or certification body which evidence it expects for 03.03.05 before the assessment begins.
