What CC7.3 asks you to do with security events and why SOC 2 auditors test it
CC7.3 asks you to have a defined way to decide whether a security event is a security incident, meaning it could cause, or has caused, a failure to meet your objectives, and to act on that decision to prevent or address the failure. If your compliance lead or engineers can show alerts flowing in but cannot show who classified them, against what criteria, and what happened next, the control is weak regardless of how good the detection tooling is. Auditors test the decision trail, not the alert count.
The usual failure is events that are noticed but never classified. A SIEM rule fires, someone glances at it, and the alert closes without a recorded verdict. This happens for three reasons: volume overwhelms a small team, ownership of the queue is unclear between operations, engineering and security, and there is no severity model that tells a responder when an event must become a case. The distinction from neighboring criteria matters. CC7.2 covers the detection side, namely monitoring and filtering that surfaces anomalies. CC7.4 covers the response once an incident is confirmed. CC7.3 sits between them and is the step where a human or documented procedure makes the call. Ask your team to pull ten recently closed alerts and show the classification, the owner and the reason for closure.
When confidentiality or privacy is in scope, CC7.3 adds an expectation to assess the impact on confidential or personal information and to determine what was accessed, used or disclosed. Confirm with your auditor early whether those points of focus apply to your system description, because they change what your triage record must capture. The TSC and its points of focus are published by the AICPA in the 2017 Trust Services Criteria with revised points of focus, which is the text to check your procedures against.
Which systems, alert sources and teams fall under CC7.3
CC7.3 applies wherever security events are generated and triaged, so the scope starts with the production systems and the log sources feeding them. The cards below cover the components, people and third parties an assessor will ask you to account for, and what changes when confidentiality or privacy is in scope.
Production hosts and workloads
Servers, containers, and virtual machines that run the in-scope service are the first source of security events. Confirm which hosts write authentication, privileged command, and file integrity logs, and that every one of them forwards those logs to the central analysis platform. A host that logs locally but never reaches the SIEM is a gap an assessor will find when they sample events from a period.
Network devices and boundary logs
Firewalls, load balancers, VPN concentrators, and DNS resolvers show traffic patterns that host logs miss. Decide which devices are in scope, which events each one must send, and how long those records are kept. Confirm that clock synchronization is consistent across devices so that correlated events can be ordered correctly during evaluation.
Cloud control plane and SaaS admin logs
Cloud provider audit trails and administrative logs from SaaS tools record who changed access, storage, or security settings. These sources are often outside the infrastructure team's direct view, so assign an owner for each one and confirm that the platform ingests them. Administrative logs from identity providers and code repositories belong here too, since they show how production access was granted and used.
Triage roles and on-call responders
CC7.3 expects a defined person or group to decide whether a security event is an incident. Name the triage owners, the backup for each shift, and the criteria they use to escalate. Keep a record of who reviewed each alert, because an assessor will sample alerts and ask who evaluated them and when.
Third-party and vendor alert feeds
Alerts from managed security providers, hosting vendors, and threat intelligence feeds can reach your team without passing through your own detection rules. Document each feed, who receives it, and the procedure for evaluating it. Confirm the contractual channel for notifications from subservice organizations, since their alerts may affect your commitments to customers.
Confidential and personal data in scope
When confidentiality or privacy is in scope, every evaluated event needs a second question: did it touch confidential or personal information, and if so, what was used or disclosed? Identify the systems that store that data, mark them in the asset inventory, and make sure triage staff can see which records are affected. This step adds work to each evaluation and should be reflected in the procedure and the case records.
How an assessor tests CC7.3 in a Type 1 and a Type 2 examination
In a Type 1 examination, the assessor evaluates whether the CC7.3 control is suitably designed and in place as of a specific date. The main work is reading the written triage procedure and confirming that it describes who reviews detected security events, how each event is classified, what severity levels mean, when an event becomes an incident, and who is told. The assessor then checks that the described tools and roles exist on that date, such as a monitored alert queue, a named triage owner and an escalation path. Because there is no observation period, the assessor generally does not test a sample of past events.
- Written triage procedure: The assessor looks for a document that defines the steps from alert to disposition, not just a general statement that events are monitored.
- Defined severity and escalation criteria: Thresholds that move an event into incident handling should be explicit enough for two analysts to reach the same result.
- Named owners: Each step should name a role or team, and the assessor will ask whether those people have access and training.
- Tool configuration on the test date: Screenshots, configuration exports or detector lists showing that the alerting pipeline was active on the as-of date.
- Privacy and confidentiality steps: If those categories are in scope, the design should say how the impact on protected information is assessed.
Before fieldwork, confirm with your auditor exactly which date and which evidence they expect for the design walkthrough.
In a Type 2 examination, the assessor tests operating effectiveness over the observation period. The assessor starts from the population of detected security events across that period, selects a sample, and traces each sampled event to a documented decision and any resulting action. The sample is chosen by the assessor, and the population must be complete for the sample to mean anything. A common early request is a full export of alerts or tickets for the period, which the assessor uses to confirm completeness before selecting items.
- Population completeness: The assessor checks that the alert and ticket exports match the monitoring tool's counts, so that no events are silently excluded.
- Sample tracing: For each sampled event, the assessor looks for the triage record, the classification, the reviewer, the timestamp and the disposition.
- Escalation checks: Events classified as incidents should show a link to an incident record and evidence that the required people were notified.
- Consistency over time: The assessor compares how similar events were classified early and late in the period.
- Exceptions: Any sampled event that does not follow the procedure is documented as an exception and evaluated for its effect on the control.
Confirm with the auditor the sample size method and whether they want the population exported from the monitoring platform or from the ticketing system.
Most CC7.3 exceptions come from gaps between the documented procedure and the records that exist. Assessors do not usually fail a control for a single missed alert, but repeated patterns in a sample can lead to an exception in the report, and the auditor's view of severity depends on the scope and the nature of the events. Knowing the common patterns lets you check your own records before the auditor does.
- Events with no recorded disposition: An alert was reviewed or auto-closed without a note saying what was decided and why.
- Inconsistent severity: Similar events were given different severity levels by different reviewers, with no rationale in the record.
- Procedures not followed: The written steps call for a second reviewer or a specific escalation, but the records show the steps were skipped.
- Missing escalation evidence: An event was classified as an incident but there is no link to an incident ticket or no record of notification.
- Gaps in the population: Detectors were disabled or a log source stopped forwarding for part of the period, and no one recorded it.
Before the examination, review a sample of your own triaged events against these patterns and ask your auditor how they would treat any exceptions you find.
Which evidence an assessor requests for CC7.3 and where findings usually come from
This table lists the evidence an assessor typically samples for CC7.3, what each item must show, and where exceptions tend to appear. Read each row as a question the auditor will ask, then check whether your records answer it without reconstruction. The main takeaway is that a written procedure without dated, dispositioned tickets behind it usually produces the findings.
| Evidence area | What the assessor checks | Where findings usually come from |
|---|---|---|
| Written event evaluation procedure | Documented steps for deciding whether an event is a security incident, who decides, and when | Procedure exists but does not match how analysts actually triage alerts |
| Severity and classification scheme | Defined levels tied to impact on objectives, including confidentiality or privacy impact | Severity labels applied inconsistently or never linked to escalation thresholds |
| Sampled event tickets with disposition | Each sampled event has a timestamp, analyst, classification and documented closure reason | Tickets closed without rationale, or dispositions added after the sample was requested |
| Escalation records | Evidence that events meeting criteria were escalated to incident response in time | Escalation paths unclear, or escalations made by chat with no ticket reference |
| Impact assessment records (confidentiality or privacy in scope) | Record of what confidential or personal information was affected and whether it was used or disclosed | Impact not assessed for events involving sensitive data, or assessment left open |
| Alert tuning and review records | Evidence that detection rules are reviewed and that false positive decisions are approved | Rule changes made without a record of who approved them or why |
| Tool-generated event population | Completeness of the alert population from the SIEM or detection platform used as the sample source | Assessor cannot confirm the population is complete, so sampling is limited |
How to build an event evaluation process that produces evidence
This sequence turns raw alerts into documented decisions, so an auditor can trace each security event from detection to a recorded disposition and, where personal or confidential data is involved, to an impact assessment.
Define events and incidents against objectives
Write down what counts as a security event (any observed occurrence worth examining) and what counts as a security incident (an event that could cause or has caused a failure to meet your service commitments and system objectives). Tie the definitions to the objectives in your system description so the test for an incident is your own stated commitments, not a judgment made case by case. The output is an approved definitions document, dated and owned by a named role, that the auditor can compare against your objectives.
Set severity and classification criteria
Define severity levels and the criteria that place an event into each one, such as affected asset criticality, whether confidential or personal information is exposed, and whether customer-facing service is impaired. Include a rule for events that cannot yet be classified so they are not dropped. The output is a severity matrix with examples of each level, approved by management, which lets an auditor see that triage decisions follow a consistent standard.
Route alerts into one case record
Send detections from monitoring tools into a single case or ticket system so each event has one record that holds the source alert, related findings, assets, notes and actions. Detection tools such as OpenSearch Security Analytics and Wazuh can generate findings and alerts, and DFIR-IRIS can triage alerts from SIEM and other sources into cases with an audit trail. Confirm the routing works for the alert types you rely on. The output is a sample of alerts traced to case records, showing that nothing reviewed was left outside the system of record.
Assign triage ownership and timelines in writing
Name the people or on-call rotation responsible for reviewing new events, the backup for absences, and the escalation path to the incident response lead. Write the expected review steps and any response timelines you set for each severity level in the procedure, using only targets your organization has actually agreed to meet. The output is a signed or approved triage procedure and an on-call schedule, which together show who was responsible at any given date.
Record the disposition for every event
For each event, the analyst records a disposition: dismissed as benign with reasoning, linked to a known issue, escalated as a security incident, or closed after action. Dispositions should not be left blank or set to closed without explanation. Include who made the decision and when. The output is a case record for each event showing its disposition, supporting notes and approval, which an auditor can select from the population during testing.
Trigger action for confirmed incidents
When an event is classified as a security incident, open the incident response workflow, record the containment and remediation actions taken, and link them to the same case. The output is a traceable chain from the original event to the incident response actions, so the auditor can confirm that events meeting the incident definition were acted on rather than only logged.
Assess impact on confidential or personal data
Where confidentiality or privacy is in scope, add a step to each incident that asks what confidential or personal information could have been affected, what was actually accessed, used or disclosed, and who must be told under contract or law. Record the findings in the case. Legal and privacy decisions belong to the organization, and counsel should confirm notification duties. The output is a documented impact assessment attached to each relevant case, which shows the assessment was performed and reviewed.
Review the process and its records periodically
Have a responsible owner review a sample of closed cases against the definitions, severity matrix and triage procedure, and record any gaps and the fixes assigned. Confirm that tooling changes, such as new detection rules, are reflected in the procedure. The output is a dated review record with findings and remediation items, which demonstrates that the event evaluation process is monitored over the examination period.
How open-source detection and case tools support event evaluation
The organization owns the decision on whether an event is a security incident, and open-source tools only produce the records that support it. For CC7.3, a detection layer such as OpenSearch 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 be sent to channels such as Slack or email. Its correlation engine links findings across log types in a correlation graph, which helps an analyst see whether a login anomaly, a configuration change and a data transfer belong to one event. Wazuh plays a similar role on the host side: it compares each decoded event against a ruleset of over 3,000 built-in rules and decoders plus custom rules, writes matches to alerts.log and alerts.json, and maps them to MITRE ATT&CK.
A finding is an input to evaluation, not an evaluation. A rule match says something happened that a rule author anticipated, and it does not say whether the event could cause a failure to meet the organization's objectives. The reader should confirm, for each rule set, who reviews findings, how severity is defined, and how false positives are tuned and documented, since those choices decide whether the output is useful evidence for the criterion.
DFIR-IRIS covers the step after triage. It triages alerts from SIEM, EDR and REST sources into cases, keeps each case as one record of assets, IOCs, tasks and evidence with a full audit trail, and builds a consolidated investigation timeline. It logs evidence with SHA-256 verification and chain of custody, and generates reports from case data. Before adopting any of these tools, confirm in your own environment that they ingest your log sources, meet your retention and access requirements, and integrate with your ticketing and notification processes. Each tool's fit should be tested with your data, not assumed from its documentation, which you can review in the DFIR-IRIS documentation.
Evidence that passes CC7.3 and how to keep it current between audits
An auditor testing CC7.3 looks for a written procedure, a consistent severity scheme and a trail that links each detected event to a decision. The cards below cover the records that show this chain, and the routine exports that keep them complete across the observation period.
Written evaluation procedure with version history
The procedure states how an event is triaged, who decides whether it is a security incident, and what happens when it is. Keep each revision with its approver and date so the auditor can see which version applied during the period. Check that the document names the systems that feed the process, such as the SIEM and the case tool, and that the steps match what analysts actually do.
Severity scheme with defined criteria
A severity scheme turns a raw alert into a decision about priority and escalation. Define each level by observable criteria, such as affected asset classification, data type and whether the event touches a system in scope. Confirm that analysts apply the same scheme to every event and that changes to the thresholds are recorded.
Case or ticket export per event
Each event that is evaluated should have a case or ticket showing the initial alert, the analyst's assessment, the disposition (incident, false positive or benign), and the closure reason. Include escalation and approval steps with timestamps. Export these records on a schedule so gaps appear during the period, not during fieldwork.
Alert routing configuration
Show how alerts reach the people who evaluate them: the notification channels, the recipients, the on-call rotation and the rules that suppress or route noisy detections. Keep exported configuration files under version control so each change has a reviewer and a date. Confirm that routing covers every log source named in the monitoring scope.
Impact assessment memos for personal and confidential data
When confidentiality or privacy is in scope, each security incident needs a short memo that states what information was on the affected system, whether it was accessed, used or disclosed, and who was notified. Ask the legal or privacy owner to sign it. Memos for events that did not involve such data are useful too, because they show the scoping decision was made.
Periodic review minutes
Management reviews a sample of closed events and the open backlog at a set interval, and records the findings, decisions and follow-up actions. The minutes show that the evaluation process is monitored and improved, which supports the review expected by the monitoring criteria. Schedule these reviews as calendar items so they recur without an audit trigger.
What meeting CC7.3 costs in money and effort
This table compares the main cost components of evaluating security events under CC7.3, who is paid for each, whether it is one-time or recurring, and what drives it up. Open-source tooling removes license spend, but hosting, tuning, triage and evidence upkeep still carry cost, so use the drivers column to frame your quote request.
| Cost component | One-time or recurring, and who is paid | Main drivers |
|---|---|---|
| Tooling and licenses | Licenses are avoided with open-source tools such as OpenSearch, Wazuh and DFIR-IRIS, but self-hosting still needs infrastructure, storage and support time, recurring | Log volume, retention period, number of log sources, high availability needs |
| Engineering time to tune rules and routing | One-time at deployment, then recurring as rules change; paid to internal staff or an implementation partner | Number of detectors, custom Sigma or Wazuh rules, alert channels such as Slack or email |
| Triage staff time | Recurring; paid through internal security operations staff or a managed service | Alert volume, false positive rate, after-hours coverage expectations |
| Evidence upkeep | Recurring; paid through internal time to keep alert records, case notes and review sign-offs complete | Number of events reviewed, case reporting requirements, evidence retention rules |
| External review of the procedure | Periodic; paid to an outside reviewer or consultant if the organization chooses to commission one | Procedure complexity, whether privacy or confidentiality is in scope, prior audit exceptions |
| Auditor sampling effort | Recurring per examination period; paid to the independent CPA firm under its engagement letter | Population size of events, number of control owners, quality of the evidence trail |
| Privacy impact assessment of events | Recurring per event that touches personal or confidential data; internal staff or counsel time | Whether privacy or confidentiality is in scope, data classification quality, breach notification duties |
Which self-hosted tools produce CC7.3 evidence
OpenSearch Security Analytics, released under Apache-2.0, runs detectors against ingested logs from hosts, network devices and cloud services. Each detector applies prepackaged or custom Sigma rules, and every match is recorded as a finding that carries the rule, the log type and a severity. This gives the security team a timestamped record of what was flagged and why, which supports the evaluation step CC7.3 asks for. The correlation engine links findings across log types in a correlation graph, which helps show whether separate events belong to one activity.
- Detector configuration: Exported detector definitions and rule sets show which conditions the organization chose to evaluate.
- Findings history: Stored findings with rule, log type and severity show what was matched and when.
- Alert routing: Records of alerts sent to channels such as Slack or email show that notification occurred.
- Correlation graph: Linked findings across log types can support the analysis of multi-stage activity.
- License note: Apache-2.0 permits commercial use and modification, so confirm which OpenSearch distribution and plugin versions your environment runs.
Confirm with your own environment that log sources are complete, that detectors run as configured, and that the retention period for findings meets your SOC 2 evidence window.
Wazuh, released under GPL-2.0-only, decodes collected logs and compares each event with a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matching events are written as alerts to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques, and forwarded to the Wazuh indexer for review in the dashboard. Those files give an auditor a plain, machine-readable trail from a raw event to a classified alert, which is central to showing that security events were evaluated.
- Alert files: alerts.log and alerts.json preserve the matched events with rule identifiers and severity.
- Ruleset provenance: Built-in and custom rule files, under version control, show which detections were in force on a given date.
- ATT&CK mapping: Technique tags on alerts help show how events were categorized during review.
- Indexer records: Alerts forwarded to the Wazuh indexer and reviewed in the dashboard can document analyst triage.
- License note: GPL-2.0-only has copyleft obligations if you distribute modified Wazuh code. Internal use alone generally does not trigger distribution, but ask counsel to confirm how your deployment and any packaged changes are treated.
Confirm with your own environment which rules are enabled, how custom rules are approved, and whether alert files are retained long enough to sample during the observation period.
DFIR-IRIS, released under LGPL-3.0-or-later, holds each investigation as a single case containing assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases, which is where the evaluation decision is recorded and acted on. It also builds a consolidated investigation timeline, logs evidence with SHA-256 verification and chain of custody, and generates reports from case data. These features give the auditor a record of how each event was judged, by whom and with what outcome.
- Case records: Each case preserves assets, IOCs, tasks and the audit trail of changes.
- Alert triage: Alerts from SIEM, EDR and REST sources converted into cases show how events moved into formal review.
- Investigation timeline: A consolidated timeline supports the analysis of what happened and when.
- Evidence integrity: SHA-256 hashes and chain of custody entries show that collected evidence was not altered.
- License note: LGPL-3.0-or-later applies to the library and may carry different obligations for modifications. Review the license for the exact components you deploy.
Confirm with your own environment that case templates, decision criteria for declaring an incident and report formats match what your auditor will ask to see.
Where CC7.3 programs usually fall short
Most CC7.3 failures are not missing tools. They are gaps between detection and decision: events that are seen but never closed, severity that drifts between analysts, and procedures that stop matching the environment. Each card below names one gap and the fix an assessor will expect to see in the evidence.
Alerts without dispositions
Alerts pile up in the dashboard with no recorded outcome. CC7.3 asks whether each security event was evaluated to decide if it is a security incident. Every alert needs a closing disposition such as false positive, benign, incident or escalated, with the name of the reviewer and the date. Check a sample of alerts from the last observation period and confirm each one ends in a recorded decision.
Severity applied inconsistently
Two analysts looking at the same event assign different severity, so some events get escalated and others are quietly closed. Write a severity scale that ties each level to impact on objectives, including confidential or personal information where in scope, and document the reasons for any override. Ask whether rule severities in the monitoring tool match the written scale.
No link between alert and case
An alert is judged in the SIEM, but the investigation lives in a ticket, chat thread or spreadsheet with no reference back. An assessor cannot trace an event from detection to decision to action. Open a case for every event that is confirmed as a potential incident, record the alert identifier in the case, and keep one audit trail from first alert to closure. Tools such as DFIR-IRIS can hold alerts, assets and evidence in one case record.
No written impact assessment for personal data
When confidentiality or privacy is in scope, CC7.3 expects the team to assess what confidential or personal information was affected and whether it was used or disclosed. Many programs skip this step and go straight to remediation. Add a short impact template to every incident case that asks which data stores, data subjects and recipients were involved, and keep the completed assessment with the case.
Tools configured but triage not recorded
Detection rules are tuned and dashboards are live, yet nobody can show who reviewed what or when. The monitoring stack is then evidence of capability without evidence of operation. Export triage records on a schedule, keep reviewer sign-off with the findings, and confirm that the alert pipeline in your platform retains its history for the full audit period. Ask your auditor which records they will sample before fieldwork starts.
Procedures not reviewed after changes
Triage procedures written for the original stack often outlive the platform they describe. New log sources, cloud accounts or a migrated SIEM can leave detection and escalation steps out of date. Set a review trigger tied to change management, so any new log source, rule set or tool change prompts an update to the evaluation procedure and a note in the change record. Keep the dated revision history for the auditor.
CC7.3 questions buyers and engineers ask before starting
How much extra effort does CC7.3 add to an existing SOC 2 program?
For most organizations that already run logging and alerting, CC7.3 adds less new tooling than it adds process. The main effort is defining what counts as a security event that could cause a failure to meet objectives, writing the triage and escalation steps, and keeping a record of how each event was evaluated and closed. The size of the increase depends on alert volume, how many log sources feed the monitoring, and whether analysts already triage alerts in a ticketing system. Teams with clear severity levels and a single case record usually find the work manageable. Ask any consultant to break their quote into alert tuning, procedure writing, and evidence design so you can see where the hours go.
Can open-source tools produce CC7.3 evidence without a license fee?
Open-source tools can generate most of the evidence CC7.3 needs, but the license question is only one part of the cost. Wazuh, OpenSearch Security Analytics, and DFIR-IRIS each cover a different link in the chain: detection and alerting, correlation of findings, and case management with an audit trail. Their own licenses are open source, so software cost is not the constraint. The real costs are hosting, storage for retained logs, and the staff time to tune rules and maintain the platform. Confirm the license terms and any commercial support options with each vendor, since the open-source projects and their enterprise offerings differ. Ask your auditor which records they will accept as evidence before you commit to a stack.
What does the internal team need to own for CC7.3?
The organization owns the control, so someone internal must own the event evaluation decisions even if an outside partner builds the platform. Staffing needs include a person accountable for the security monitoring procedure, analysts who can classify events and decide whether they are security incidents, and an approver who signs off on closures and escalations. Engineers need to understand which log sources feed the detectors and how rules are changed under change management. If the team is very small, document who covers each role, including after hours, and confirm that the same people are not both creating and closing the same alerts without review.
Can an outside partner set up the CC7.3 monitoring and evidence?
Yes, an implementation partner can plan, deploy, configure and document the monitoring stack and the evidence workflow inside your own infrastructure. DeployOpen works this way: it prepares systems, controls and evidence for an assessment, while the organization keeps ownership of its decisions and the CPA firm issues the report. A fixed-scope engagement should list the detectors, log sources, case workflow, documented procedures and evidence exports in writing before work starts. Ask the partner to state what it will not do, such as making triage decisions or signing incident closures, and confirm who keeps administrative access after handover.
How does the auditor sample security events in a Type 2 examination?
In a Type 2 examination the auditor tests whether CC7.3 operated across the observation period, so the sample is drawn from the population of events your team recorded and evaluated during that window. The auditor usually asks for the complete population first, checks that it is complete and accurate, and then selects items to trace from detection through evaluation, decision, and closure. Sample sizes depend on the auditor's methodology and the frequency of the control, and they should be confirmed with your CPA firm rather than assumed. Records that show a timestamp, the analyst's decision, the rationale, and the link to any case are the easiest to test. Gaps such as events closed without a recorded rationale are the most common reasons for exceptions.
Does CC7.3 change when confidentiality or privacy is in scope?
Yes, when confidentiality or privacy is in scope, CC7.3 expects the evaluation to include the impact on confidential or personal information. Analysts must determine whether the event affected that information and record what data was accessed, used, or disclosed. This affects triage criteria, case templates, and the timing of escalation, since legal or contractual notification duties may apply. The privacy criteria and your customer contracts will define what must be assessed and to whom it must be reported. Confirm those obligations with counsel and your CPA firm before you finalize the procedure, because the definitions of personal information differ across jurisdictions and contracts.
How DeployOpen scopes and prepares CC7.3 evidence
DeployOpen plans, implements and documents event evaluation workflows inside the client's own infrastructure, on a fixed scope agreed in writing before work starts. The scope usually fixes which log sources feed the evaluation (hosts, network devices, cloud control planes and the SaaS applications in the system description), who triages events and who decides whether an event is a security incident, and where the decision record lives. From there DeployOpen configures the self-hosted detection and case tools named in the topic guidance, such as OpenSearch Security Analytics, Wazuh and DFIR-IRIS, and tunes detectors and rules so the triage queue matches the agreed process. Ask any implementation partner to show the written scope, the list of log sources in it and the named owner for each triage decision before work begins.
The organization owns its controls. That means management decides the severity thresholds, the escalation path to the incident commander, and whether an event could have affected confidential or personal information. DeployOpen prepares the systems, the case templates and the evidence those decisions produce, such as detector configurations, alert and finding exports, case records with their audit trail, and the timelines built during investigations. Where confidentiality or privacy is in scope, the impact assessment fields and the data-use questions are built into the case workflow so the record shows what was assessed and what was concluded. Confirm with your CPA firm which sample of events and cases it will select, because that sample determines which records must be retrievable.
DeployOpen does not issue SOC 2 reports, attestations or opinions. Only the independent CPA firm performing the examination can do that, and it tests the controls as they operate over the period it covers. Before engaging, ask the partner which deliverables are fixed in the written scope, how evidence is handed over, and what the client must keep running after hand-off, including detector maintenance and rule updates. Plan for that recurring work, because a Type 2 report depends on the evaluation process operating consistently across the whole observation period, not only on the day the tools were installed.
