CC7.2 Monitoring for anomalies: SOC 2 requirements

What CC7.2 monitoring for anomalies asks a SOC 2 team to prove

CC7.2 asks the organization to monitor its system components and how they operate for anomalies that point to malicious acts, natural disasters or errors, and to analyze those anomalies to decide whether they are security events. In practice, a SOC 2 team has to show two things: that monitoring is running across the in-scope environment, and that someone reviews what it finds and makes a documented decision about each significant signal. The organization owns this control. An implementation partner can prepare the logging, detection tooling and evidence, and the CPA firm tests whether the control operated over the examination period. Neither the partner nor the tool issues the opinion. The risk is simple to state. An intrusion that goes unnoticed for weeks, a failing disk that corrupts a database, or a misconfigured service that leaks data can all appear first as ordinary-looking activity in logs. The difficulty is that the signal is buried. Log volume from servers, identity providers, applications and cloud accounts is large, alert rules that fire constantly get ignored, and many teams cannot say who owns the queue at 2 a.m. An auditor will look for those weaknesses as much as for the tool itself. Confirm early which systems are in scope, which log sources feed the monitoring, who receives alerts, and what the escalation path to a security event decision looks like. For the evidence file, the strongest position is a short written detection policy, a list of monitored sources, rule or detector definitions with change history, and a sample of alerts showing triage notes and outcomes, including alerts closed as benign. Open-source platforms can produce much of this. Nextcloud's admin_audit app writes events to audit.log, OpenBao audit devices record API requests and responses in JSON, and OpenSearch Security Analytics and Wazuh match ingested logs against rules and record alerts. Confirm with your CPA firm how they expect alert review and tuning decisions to be documented before you choose which platform generates the record.

Which systems, logs and teams fall under CC7.2 monitoring

CC7.2 monitoring is only as wide as the system description the auditor tests against. The scope decisions below determine which components produce logs, how many detection rules are needed, and who reviews the alerts. Settle them before choosing tools, because every later decision depends on them.

Production and supporting infrastructure

Start with every component named in the system description: production workloads, the networks between them, load balancers, bastion hosts and the CI/CD systems that deploy to production. Supporting infrastructure such as backup servers and monitoring stacks is also in scope when it can affect the services being examined. For each component, record which events it emits and where they go. A component that is in scope but sends no logs to a central store is a monitoring gap the auditor will ask about.

Identity providers and access logs

Sign-in events, failed authentications, MFA challenges, role changes and token issuance usually reveal the anomalies that matter most. Confirm that the identity provider is in scope, that its logs reach the detection platform, and that alerts cover impossible travel, repeated failures and privilege grants. Ask whether administrator actions on the identity system are logged separately from user sign-ins, since both need coverage.

Databases and data stores

Database logs record queries, schema changes, privilege grants and failed connections. Decide which databases hold customer data or credentials and monitor those first, because they set the sensitivity baseline for the rest of the scope. Query-level logging can be voluminous, so the scope decision should say which events are retained, for how long, and which are sampled or filtered.

Cloud control planes and endpoints

Cloud control plane audit trails show resource creation, policy changes, key use and disabled logging, which are common signs of an intrusion. Endpoints such as administrator laptops and build agents add process and file activity. Confirm whether each cloud account and each endpoint class is in scope, and whether a cloud-level logging setting that an administrator can switch off is itself monitored.

Applications and secrets stores

Application logs and secrets store audit devices capture authorization failures, unusual API patterns and access to credentials. OpenBao, for example, records a detailed JSON log of each API request and response, with most sensitive values hashed. Decide which applications and secrets stores are in scope and whether their logs contain personal or confidential data, since that affects how the logs are stored and who may read them.

Subservice organizations and their reports

When a cloud provider, hosting company or managed monitoring vendor performs part of your monitoring, that party is a subservice organization. Your CC7.2 control can rely on its SOC report and on your own review of the alerts it sends you, but you must document which monitoring activities it performs and which remain yours. Ask each vendor what it logs, how long it retains records and how it notifies you of a detected event.

How a SOC 2 auditor tests anomaly monitoring

This table compares what an independent CPA firm typically tests for CC7.2, the evidence it requests, and the findings that most often appear. Read each row as a question the auditor will ask, then check whether your records answer it for the full observation period in a Type 2 examination.

Test area	Evidence the auditor requests	Common findings
Alert rule configuration	Exported detection rules or Sigma-style rules, change history for each rule, and the documented rationale for thresholds and filters	Rules changed without approval records, or rules that were disabled and never re-enabled
Log source coverage	Inventory of in-scope components mapped to the log sources forwarded to the detection platform, with timestamps showing continuous collection	New production hosts, cloud accounts or admin tools absent from the log source list
Alert triage sample	A sample of alerts drawn across the period, each with the analyst's triage notes, the decision on whether it was a security event, and the follow-up ticket	Alerts closed with no reason recorded, or no documented decision on whether an alert was a security event
Detection tool health	Evidence that the detection and log pipeline ran across the observation period, such as service uptime reports, agent heartbeat records and error alerts	Agents or forwarders that stopped reporting for weeks without anyone noticing or documenting the gap
Filter and suppression review	Records of alert filters, their owners, and periodic reviews showing that suppressed events still fit the risk assessment	Broad suppression rules with no review date, hiding categories of events from analysts
Escalation path	Documented routing for alerts to on-call staff or channels, and records showing that escalations reached the named owner	Escalations sent to a channel nobody monitors after a staff change

How to implement anomaly monitoring step by step

This sequence turns CC7.2 from a policy statement into a working pipeline: known components, centralized logs, tuned detections, a reviewed alert queue, documented triage and a check that the monitoring itself still works.

Define monitored components and expected behavior
Start with an inventory of the system components in SOC 2 scope: production hosts, databases, identity providers, secrets management, network boundaries and the applications that handle customer data. For each component, the engineering owner writes down what normal activity looks like, such as typical login volumes, administrative actions, API error rates and data transfer patterns. Done means every in-scope component has an owner and a short baseline note that the security lead has reviewed.
Centralize logs from every source
Configure each in-scope component to send its logs to one central store that the operations and security teams can query. Examples include application audit logs (for instance, the admin_audit app in Nextcloud writes extra event detail to audit.log in the data directory or to a path set with logfile_audit), OpenBao audit device output, which records every API request and response with most sensitive values hashed, and host or cloud logs. The output is a log source inventory that lists each source, its format, retention location and the person responsible for it. Confirm that log transport is protected and that the central store restricts who can alter or delete entries.
Build detection rules and noise filters
Translate the expected-behavior notes into a rule register. Each entry names the anomaly it targets, the log source, the condition, the severity and the owner. Detection platforms can help: OpenSearch Security Analytics runs detectors against ingested logs using prepackaged or custom Sigma rules and records matches as findings with a rule, log type and severity. Wazuh compares each decoded event against its built-in ruleset of over 3,000 rules and decoders plus custom rules, and maps alerts to MITRE ATT&CK. Add filters to suppress known benign patterns, but record every filter with its reason and approver so the filters themselves can be reviewed later. Done means the rule register is approved and each rule has a test event that fires it.
Route alerts to a reviewed queue
Send matching findings and alerts to one queue that a named team checks on a set schedule, using channels such as email or chat only as notifications that point back to the queue. Define who is on rotation, what each severity level must receive, and how a silent or unassigned alert is escalated. The output is an alert routing matrix and a queue configuration record. Confirm that an alert cannot be closed without a reviewer's name attached, because the auditor will sample closed alerts to test operating effectiveness.
Document the triage decision for each anomaly
For every alert the reviewer decides whether the anomaly is a security event, a benign error or a false positive, and records the reason. Use a triage record template with fields for alert identifier, component, date reviewed, reviewer, evidence examined, decision, linked ticket and follow-up owner. Escalate anything that could be a security event to the evaluation process in CC7.3. The output is a completed triage record for each reviewed anomaly, which is the primary evidence an assessor samples for CC7.2. Ask your CPA firm to confirm the exact sample population and period they will test.
Tune rules from triage results
Review triage outcomes on a recurring basis to find rules that generate mostly false positives and rules that missed events found by other means, such as a penetration test or a user report. Adjust conditions, severities and filters, and log each change in the rule register with the reason and approver. This closes the loop the CC7.2 points of focus describe: detection measures are designed, filters analyze anomalies, and the tools are kept working. The output is a change history for the rule register that shows tuning was deliberate and reviewed.
Monitor the detection pipeline itself
Set up checks that confirm the monitoring still works: that each log source is still sending, that the central store is ingesting, that detectors are running and that the alert queue is being reviewed. Test the pipeline periodically with a known benign test event that should always fire a rule, and record the result. Tell the operations team what happens when a source goes quiet. The output is a pipeline health record and a test log. Without this step, an assessor can find that a monitoring gap existed for a period even when the alert queue looked clean.

How logs, detectors and alert filters turn anomalies into security events

CC7.2 is satisfied by a pipeline, not by a tool, and the auditor will test each stage of it. Application and system logs are generated, collected from hosts, applications and cloud services, normalized into fields that rules can read, and then matched against detection rules. Each match becomes a finding or an alert. An analyst then filters that output and decides whether the anomaly is a security event that needs evaluation under CC7.3, or an error, a known benign pattern or a natural cause. The organization owns every stage. A partner can design and configure the pipeline, but the decisions made inside it belong to the people named in the monitoring procedure.

Filtering is a designed control, not just noise reduction. CC7.2 expects the organization to implement filters that analyze anomalies, so the suppression rules, severity thresholds and routing logic must be written down, approved and reviewed like any other control. A filter that silently drops a class of events can hide the exact activity the detector was built to catch. Before go-live, confirm who may change a suppression rule, how changes are logged, and how the team tests that the detection tools still fire on known test events. Ask whether the monitoring of the detection tools themselves, such as log source health and rule execution, is scheduled and evidenced.

The decision record is what the auditor will sample. For a Type 2 examination, the auditor typically selects alerts across the observation period and asks for the original log entry, the rule or finding that fired, the analyst's disposition, and the reason for closing or escalating it. Gaps in that trail, such as alerts closed with no note or log sources that stopped reporting for weeks, are common exceptions. Plan retention for logs and alert records against the observation period, and confirm with the auditor in advance which dispositions and sample sizes they expect.

Evidence that passes CC7.2 and how to keep it current

A SOC 2 examiner tests CC7.2 by asking whether monitoring existed, covered the right components, and kept working across the whole observation period. The cards below are the records that answer those questions. Keep them generated from the systems themselves, so the evidence for a Type 2 period is produced as the period runs rather than rebuilt at audit time.

Log source inventory

This is the list of every system component that feeds monitoring: identity providers, servers, container platforms, databases, the secrets store, file sharing and network devices. Each entry should name the owner, the log type, the destination and the date it was onboarded. A new service that never appears here is the most common gap an examiner finds. Generate the inventory from the collection configuration or infrastructure as code, and reconcile it against the asset register each quarter. Confirm with your auditor whether they expect the inventory to be a point-in-time list or a version history.

Log retention configuration

Retention settings show how long audit records survive and where they are stored. Capture the configuration files and their change history, including the audit log path and the rotation policy for each self-hosted platform. For Nextcloud, the admin_audit app writes to audit.log in the data directory or to a path set with logfile_audit, so the chosen path and its permissions belong in the evidence. Check that rotated logs are archived to protected storage rather than deleted, and sample a period to confirm records exist for every day.

Detection rule register with change history

The register lists each detection rule, its log source, its severity, its owner and the reason it exists. Store it in version control so every edit, addition and retirement carries an author, a date and an approval. OpenSearch Security Analytics detectors match logs against prepackaged or custom Sigma rules, and Wazuh compares events against a built-in ruleset plus custom rules, so both the rule files and the deployed state must match the register. An examiner will ask who approved the last change and whether it was tested before it went live.

Sample alert and triage records

Every alert needs a recorded decision. Keep the alert, the analyst who reviewed it, the time of review, the determination (benign, false positive, or escalated to a security event under CC7.3) and the reasoning. Wazuh writes matches to alerts.log and alerts.json, and OpenSearch records findings with rule, log type and severity, so the raw records can anchor each sample. Auditors typically select samples across the period, so an alert queue that is reviewed only in bulk will produce weak evidence. Ask your auditor how many samples and which period they plan to select.

Filter and suppression approvals

Filters that drop, group or suppress alerts reduce noise, but they can also hide the anomalies CC7.2 expects you to catch. Each filter should have a written justification, a named approver who is not the author, a scope limited to specific sources or rules, and a review date. Keep the filter definitions in version control alongside the detection rules so a suppression cannot be added silently. Periodically test whether suppressed events would still have been visible in the logs, since an examiner may ask how an analyst would notice a suppressed attack.

Proof that detection tooling was healthy

Monitoring that silently stops is a control failure that does not show up in the alert queue. Keep evidence that each collector, indexer and audit device was running throughout the period: heartbeat or agent status records, health alerts for lost log sources, and records of any outage with its detection time and recovery. OpenBao audit devices write a detailed JSON log of every API request and response, including errors, so a gap in that log is itself a signal to preserve. Schedule an automated check for silent sources and store its results with the rest of the evidence.

Choosing self-hosted tooling for anomaly detection

Application audit logging records who did what inside a self-hosted application, such as logins, permission changes, file access and administrative actions. For CC7.2, this is the raw record that lets your team notice unusual activity in the application layer. Nextcloud's admin_audit app is one example: it writes additional event information to a file named audit.log in the data directory, or to a path set with the logfile_audit setting. Confirm in your own environment which events the app captures, how the log is rotated, and whether the file is protected from edits by application administrators.

Evidence produced: A dated record of administrative and user events that you can sample during the examination period.
Where output lands: A local file, which must be shipped to a central log store to be reviewed alongside other sources.
What you still build: Rules that define which events are suspicious, such as repeated failed logins or bulk downloads.
Triage process: A named owner, a review cadence and a record of what was reviewed and what was escalated.
Retention: Log retention periods that match your own policy and the period your auditor will sample.

Ask your implementation partner to show the log path, the event list and the shipping configuration before you rely on this layer for CC7.2 evidence.

A SIEM-style detection platform collects logs from many sources, normalizes them, matches them against detection rules and records the results for review. CC7.2 focuses on the design of detection measures, the filters used to analyze anomalies and the monitoring of the detection tools themselves. OpenSearch Security Analytics, licensed under Apache-2.0, runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. It records matches as findings with a rule, log type and severity, sends alerts to channels such as Slack or email, and uses a correlation engine to link findings across log types. Wazuh, licensed under GPL-2.0-only, decodes collected logs, compares each event against more than 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. Confirm which rule sets, log sources and alert channels each platform supports in your version.

Evidence produced: Findings, alert histories and rule definitions that show anomalies were detected and analyzed.
Where output lands: Dashboards, alert channels and index or file stores that need access controls and retention settings.
What you still build: Tuned rules, filters that reduce noise, correlation logic and documented thresholds.
Triage process: An analyst workflow that records disposition, escalation and links to the incident process.
Tool monitoring: Health checks showing that log sources and detectors keep running, since silent failure is a CC7.2 concern.

Ask for a walkthrough of a finding from ingestion to closure so you can confirm the workflow works in your own environment.

What meeting CC7.2 costs in money and effort

This table breaks down the money and staff time behind CC7.2 monitoring, marking each component as one-time or recurring and naming what pushes it up or down. Read it as a list of quotes to request, since no fixed figures are supplied here and the largest swing usually comes from log volume and the number of sources onboarded.

Cost component	One-time or recurring	Who is paid and what drives it
Tooling or licenses	Recurring	Commercial SIEM or log platform subscriptions, usually priced on ingested volume or sources. Self-hosted open-source platform such as OpenSearch, Wazuh or OpenBao removes most license spend but not hosting.
Hosting and storage	Recurring	Compute, indexed storage and backup for log data. Driven by log volume, number of sources and the retention period the auditor expects you to demonstrate.
Engineering time to onboard log sources	One-time, with recurring additions	Internal or implementation partner staff connect hosts, applications, cloud services and identity providers. Each new source, such as a self-hosted Nextcloud audit log or OpenBao audit device, adds decoding and testing work.
Writing and tuning detection rules	One-time, then recurring	Engineers build Sigma or custom Wazuh rules for your environment and retune them as systems change. Cost rises with the number of distinct threat scenarios you choose to cover and the amount of noise in early tuning.
Alert triage labor	Recurring	On-call or security operations staff review findings, decide what is a security event and hand off to CC7.3. Driven by alert volume after filtering, team size and how many alerts are documented as dismissed with reasons.
Evidence upkeep	Recurring	Staff export alert records, rule change history, review sign-offs and filter decisions for the observation period. Cost falls when evidence is collected automatically and rises when reviews are manual or undocumented.
External review or testing	Recurring or periodic	Independent testing of detection coverage, such as a security testing firm exercising detections. Scope and frequency are set in a written statement of work; confirm whether it is required or optional for your report.
Auditor sampling effort	Recurring, per audit period	The CPA firm samples alerts, rule changes and review records across the period. Fees follow the engagement letter; sample size grows with the number of monitored systems and the number of exceptions found.

Questions buyers ask about CC7.2 monitoring

How much effort does CC7.2 monitoring take to run?

Effort depends mostly on how many system components feed logs into detection, how many detection rules you tune, and how many alerts someone must triage each week. No supplied figure sets a fixed number of hours, so treat any estimate you receive as unverified until the partner shows its assumptions. Ongoing work usually includes reviewing alert volume, updating rules after changes to the environment, checking that log sources still report, and documenting each decision to close an anomaly as a non-event or escalate it. Ask the partner to break its quote into one-time build work and recurring operations work, so you can see which part your team must staff every month.

How long does it take to set up anomaly monitoring for SOC 2?

Setup time depends on the number of log sources, whether the platform is already deployed, how much detection content you need, and how quickly your team can approve the alert routing and escalation paths. No researched figure gives a duration, so ask your implementation partner for a written timeline tied to a defined scope. The main drivers are inventory of systems that must be monitored, access to cloud accounts and hosts, agreement on which events count as anomalies, and testing that alerts reach a person who acts on them. Expect the schedule to slip if any of these inputs arrive late.

What does the internal team need to provide?

The internal team owns the control, so it must supply the people and decisions that a partner cannot make for it. Typical inputs include:

A named owner for security monitoring and alert triage
Access to the systems, accounts and log sources in scope
Approval of the anomaly definitions, severity levels and escalation contacts
Someone who can confirm whether an alert reflects normal business activity

Without these inputs, detection tools produce alerts that no one reviews, and an assessor will find that the control does not operate.

Can a partner build the monitoring while our team keeps running the business?

Yes, a partner can prepare and implement the monitoring while your team continues its normal work, provided the scope, deliverables and access are agreed in writing before work starts. Most engagements are fixed-scope, so the partner's job is to build the logging, detection and alert paths and hand over documentation. Your team still owns the control and must run the alert process after handover. If you want the partner to continue operating the platform, that is a separate retainer agreed on its own terms. Confirm which party reviews alerts on weekends and during on-call periods.

What does a Type 2 observation period require for CC7.2?

A Type 2 report tests whether the control operated effectively over a period, so monitoring must run continuously throughout that window, not just on the day of setup. The auditor will typically sample alerts and anomaly decisions across the period and ask for evidence that each was reviewed, classified and resolved or escalated. Keep records of log retention, detection rule changes, alert tickets and the review of detection tool health. Any gap in log collection or any period when alerts were not reviewed can become an exception. Confirm the observation period length and sampling approach with your CPA firm before the window opens.

Which open-source tools produce evidence for this control?

Several self-hosted platforms can generate the logs and alerts that show monitoring is in place. Nextcloud's admin_audit app writes additional event information to an audit log, and its location can be set in the server configuration. OpenBao audit devices record detailed JSON logs of API requests and responses. OpenSearch Security Analytics matches ingested logs against Sigma rules and records findings with severity, while Wazuh compares events against a built-in and custom ruleset and writes alerts to files. Each tool needs its own log retention, access control and tuning, and the evidence still has to show that someone reviewed the output. Confirm each platform's current capabilities in its own documentation before you rely on them.

Does a partner's work make us SOC 2 compliant?

No. Only an independent CPA firm issues a SOC 2 report, and your organization owns its controls. A partner can prepare systems, configure monitoring and assemble evidence, but the report depends on the auditor's independent testing of your controls over the observation period. Ask the auditor which evidence it expects for CC7.2 before implementation begins, so the monitoring you build produces records the auditor can sample.

Who owns, builds and tests CC7.2 monitoring

Your organization owns CC7.2. Management must decide what counts as an anomaly worth investigating, who reviews alerts, how quickly they are reviewed, and when an anomaly becomes a security event that goes to the evaluation process under CC7.3. Those decisions cannot be delegated to a tool or a vendor, because the SOC 2 report describes the controls you operate. Your security or operations staff run the monitoring day to day, tune detection rules against your own environment, and keep records of each review.

Detection policy and scope: Written rules for which systems, log sources and event types are monitored, and who approves changes to them.
Triage decisions: Staff who classify alerts as false positives, benign anomalies or security events, and record the reason.
Escalation and approvals: Named owners who approve rule changes, suppressions and filter exceptions.
Review evidence: Tickets, dashboard exports or sign-offs showing that alerts were reviewed on schedule.
Monitoring of the monitoring: Checks that log collection and detection tools are still running and that gaps are noticed.

Confirm that each of these has a named owner and a record your auditor can sample.

Where CC7.2 monitoring usually falls short

Most SOC 2 monitoring programs have logs, alerts and detection tools in place, yet an assessor still finds gaps. The gaps below share a pattern: the data exists, but nobody can show that someone looked at it, decided what it meant, or kept the detection logic under control. Each card names one gap and the step that closes it.

Logs collected but never reviewed

Audit trails from applications, identity providers and infrastructure are often switched on and forwarded to storage, but no one has a defined review cadence or a named reviewer. Under CC7.2 the question is whether anomalies are actually identified and analyzed, not whether logs exist. Self-hosted Nextcloud writes admin_audit events to audit.log, and OpenBao keeps a JSON audit device log, yet neither helps until someone reviews them on a schedule. Closing step: assign a reviewer for each log source, set the review frequency, and keep a dated record of each review with its findings.

Alerts with no documented decision

A detection tool may raise alerts that are acknowledged, muted or closed without a recorded reason. An assessor testing CC7.2 will ask how an alert was analyzed and why it was judged to be, or not to be, a security event. Without that trail, the monitoring looks like noise suppression rather than analysis. Closing step: define a disposition for every alert type (benign, false positive, security event, escalated), require a written reason for each closure, and link the closure to the ticket that handled it.

Detection rules untracked in change control

Detection logic such as Sigma rules, custom Wazuh rules and filters is frequently edited directly on the console with no approval or history. If a rule is changed or disabled, the organization cannot show when monitoring coverage shifted or who approved it. Closing step: store detection rules as version-controlled files, route changes through the same review and approval path used for other production changes, and record which rule versions were active on each date.

Monitoring of the detectors missing

Teams watch their systems closely but rarely check whether the monitoring tools themselves are running. A log forwarder that stops, a full disk that halts an indexer, or a detector that silently fails leaves blind spots that no alert reports. CC7.2 expects monitoring of the detection tools for effective operation, so the organization needs evidence that its sensors are healthy. Closing step: add health alerts for each agent, forwarder and detector, and test periodically that a known test event produces an alert end to end.

Unclear ownership across teams

Logging may belong to platform engineering, detection to a security team, alert triage to a support rota, and audit evidence to compliance. When a gap appears, each group assumes another group owns it, and the assessor cannot find one accountable owner for CC7.2. Closing step: write a RACI-style table covering log sources, detection rules, alert triage, tool health and evidence collection, name one owner per row, and review the table whenever systems or staffing change.

When to bring in a partner for CC7.2 and when to do it yourself

Bring in a partner for CC7.2 when your logging and detection work is incomplete or undocumented and the audit window is close. Do it yourself when your team already collects logs from every in-scope component, has someone who can tune alerts, and can keep triage running without the work slipping during peak periods. Start with an honest inventory: which systems write audit logs today (for example, whether the admin_audit app is enabled in Nextcloud and where audit.log lands), whether OpenBao audit devices are enabled, and whether alerts from your detection tools reach a person who acts on them. If the answer to several of these is no or unknown, the gap is in the setup itself, and a partner can help build it faster than an internal team learning as it goes.

Staff time and the audit timeline decide the rest. CC7.2 is tested over the period the report covers, so the detection rules, filters and review records have to exist and work for that whole period, not just on the day of the examination. Ask whether your team can name an owner for alert review, cover that role during leave, and document each filter change with a reason. A partner can prepare and document the setup, including detection rules in OpenSearch Security Analytics or Wazuh, filter logic and runbooks, but your organization must own the decisions: which events count as anomalies, what severity triggers escalation, and which alerts are suppressed and why. Confirm these ownership lines in writing before work starts. Keep independence clear. A CPA firm will test the detection tools, the alert filters and the evidence of review on its own terms, and it will not accept a partner's description as proof that controls operate. Ask any partner to show you how each claim maps to a log source, an alert record and a human review, and ask your CPA firm early what sample of alerts and tickets it expects to see. The AICPA 2017 Trust Services Criteria is the reference for what the points of focus describe, so use it to agree scope before implementation.

How DeployOpen scopes and prepares CC7.2 monitoring evidence

DeployOpen plans, implements and documents the logging and detection stack that CC7.2 monitoring depends on, inside the client's own infrastructure. The organization keeps ownership of its controls, its alert triage decisions and its SOC 2 assertion, while an independent CPA firm performs the examination and issues the report.

How we scope

Engagements are fixed-scope, with the monitored systems, log sources and detection tools named in writing before work starts.
The written scope lists which components are in monitoring coverage, such as identity, application, database and cloud audit logs.
Scope also records who reviews alerts, how anomalies are escalated, and which Type 2 observation period the evidence must cover.

How we build

We configure audit logging on self-hosted platforms, for example enabling the admin audit log in Nextcloud and the audit devices in OpenBao.
We deploy a detection layer such as OpenSearch Security Analytics or Wazuh and tune Sigma or ruleset content to the client's environment.
We test that detectors fire on controlled sample events and document how alert filters reduce noise without hiding security-relevant anomalies.

How we hand over

Deliverables include a monitoring control narrative, a log source inventory, detector and rule configuration records, and alert routing documentation.
We document the review cadence and the records that show each alert was analyzed and classified as a security event or dismissed.
Handover includes runbooks so the client's own staff can operate detectors and produce the evidence the CPA firm will request.

How we support

Ongoing support, upgrades and continuous testing of the monitoring stack are available as retainers, agreed in writing.
Retainers can cover periodic checks that detectors still operate effectively, which is the evidence CC7.2 asks organizations to keep.
Ask any provider to confirm in writing which parts of the evidence the client owns and which parts the provider prepares.