4.3 SOC: from alert to accepted result

This guide uses a fictional alert to show the workflow for a self-built SOC business. You can practice with a local record or a table. Reading external alerts requires a read-only connection that you are authorized to use. The goal is to keep sources, responsibilities, and results available for review. This does not guarantee that a model's judgments are correct or take automatic response actions.

The steps below cover building your own business and do not require any marketplace resource. If you use a SOC template or dashboard from the marketplace, follow its detail page. Before using a real SIEM/EDR source, configure and verify your connections, data mappings and permissions, and review model output. Sample alerts and demonstration results do not establish conclusions for 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:

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.

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

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:

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:

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:

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.