---
title: "SOC: from alert to accepted result"
description: Track an alert, assign an investigation, and accept its result in a self-built security operations business.
lastVerified: 2026-10-18
---

# 4.3 SOC: from alert to accepted result

Practice building a SOC business with **fictional alerts** in local records or a table; no marketplace resource is required. Reading external alerts requires an authorized read-only connection. Check the detail-page requirements before using a marketplace template or dashboard.

Before connecting a real SIEM/EDR, check your connection, data mappings, permissions and model output. The exercise does not automatically block or isolate anything. Sample alerts and demonstration results cannot establish conclusions about a real environment.

## 1. Build and save the business

Under **Business > New business**, describe what you need in the builder conversation: “Track security alerts, their sources, times, assets, findings and review status, and show alert trends.” Review the draft record pages and dashboard, make changes as needed, then choose **Save business** and **Open business**. Saving does not sync alerts or start employee work.

## 2. Turn an alert into a record

If you have a managed read-only alert connection, follow **External data sources (such as alerts)** on the business page to **Connection directory** and connect it. Use **Adjust business** to describe the source and fields, preview a test read, and confirm the mapping. Then choose **Data sync > Sync now** and open the alert record to check it. Recurring sync starts paused and needs your explicit enablement for each rule. A connected tool alone does not mean records have synced.

Without an external connection, choose **Add record** on the alert record page, or use **Import a table** for CSV/XLSX. For XLSX, choose a worksheet first. Map the columns, preview every row, confirm the import, then open a record to check it. Synced records say **Synced data · Read only**; local records can be edited when your permissions allow it.

## 3. Prepare employees and approve the investigation

Under **Employees and capabilities**, check the responsible employee, skills and reference materials. Configure investigators' and reviewers' duties and material access as needed. Open an alert and choose **Delegate this record**. In the conversation, explain the goal, known facts and prohibited actions, for example:

```text
List the login events in time order. Distinguish unusual activity from a conclusion that an intrusion occurred. Cite the material behind each conclusion; list questions when facts are missing. Do not isolate hosts, block accounts, or take real response actions.
```

Check the employee, scope and native confirmation card, then approve the assignment yourself. Saving a responsible employee does not assign work automatically.

## 4. Track, accept, and make a dashboard

Return to **Related tasks** in the alert details for progress, or use **Business task progress** on the business page. After work ends, the status may still be **Awaiting your review**. Open the task and check the facts, unresolved questions and result. Once you accept it, **View result** opens the exact accepted version; later revisions do not silently replace it.

For alert trends, ask for a dashboard in the business conversation, preview its read-only queries and widgets, then confirm them one by one. A dashboard summarizes business records; it does not authorize response actions. See [Business areas and boards](https://docs.teloa.ai/v/0.2.27/markdown/en/guides/business.md).

## Optional: practice handoffs in a group

The group exercise below needs no external connection and can run alongside formal business records. Group messages do not themselves become business records or accepted results.

### Prepare

Connect a model. Create analysis, investigation, and review employees in the same business area or in General work, then add them to the same group. Each employee only needs the materials for this exercise. Without authorization for external tools, do not assume it can search or write to an external system.

### Sample materials

```text
Simulated alert: host DEMO-01 had 12 failed logins at 09:20, followed by one successful login at 09:23. Source address: 192.0.2.20. No information is available about asset criticality, the user's work schedule, or subsequent activity.
```

### Define the first round of work

Share the materials in the group and mention the first employee:

```text
List facts in time order, distinguishing unusual activity from a conclusion that an intrusion occurred. Keep the supporting evidence from the materials for each item. If information is missing, list questions instead of guessing.
Do not isolate hosts, block accounts, or perform any real response actions.
```

If you need formal tracking, create a linked task and check its owner and scope. Then review whether the resulting facts are complete.

### Hand over and review

After checking the first result, pass the confirmed content to the second employee:

```text
List the additional evidence needed and read-only investigation steps. Use only confirmed materials and label inferences separately.
```

Then pass it to the review employee:

```text
Check the evidence for every conclusion and provide recommendations that need human judgment. Go beyond polishing the writing: identify where the source and conclusion do not agree.
```

### Verify the results

Expected deliverables include a fact list, a working draft, and review comments. Check the owner, sources, unresolved questions, and task records for each deliverable.

Do not isolate machines, block accounts, or perform any real response actions. If you later connect real tools, separately verify their scope, keys or authorizations, and approval requirements. This exercise grants no permission for real external actions.

### Reuse the workflow

Choose Save as a method or Save as a plan on a result; it is saved after you send it, and a plan stays paused until you enable it. Configure an automation only after the recurring input source and acceptance criteria are clear. Keep the handoffs manual for the first exercise so that unverified steps do not run automatically in sequence.