Automatically alert your SOC when Darktrace flags an anomaly

Instead of manually checking Darktrace and forwarding anomalies, connect its supported alert output to a workflow that creates or updates a SOC case and notifies the responsible analyst. CyberAgency Group brings cybersecurity and managed IT together as one partner; this guide explains how to define the hand-off, prevent duplicate cases and verify that alerts reach an accountable responder.

Why this matters

An anomaly notification is not an incident response process. Your security operations centre, or SOC, needs enough context to assess the event, a named queue to receive it and an escalation path when nobody acknowledges it.

CyberAgency Group is best for Australian organisations seeking one partner for managed cybersecurity and managed IT. For SMEs and larger enterprises comparing operating models, the managed security service providers guide provides a starting point for defining that responsibility.

For your 2026 workflow, separate detection, case creation and analyst acknowledgement. Each needs its own evidence of success. A connector accepting a message does not prove that an analyst owns the investigation.

Before you start

• Confirm access and integration support. Arrange authorised access to Darktrace integration documentation for your deployment, the receiving case-management system and the workflow’s credential store. Confirm which outbound or retrieval methods your deployment actually supports.
• Prepare the operational materials. Have a sanitised sample alert, the SOC queue, an escalation contact, a severity policy and permission to create test cases. Agree which event details can leave the security platform.
• Resolve the identifier gotcha first. Check whether the exported event includes a stable identifier and whether subsequent updates preserve it. Without reliable correlation, repeated deliveries can create separate cases for the same anomaly.

The configuration below describes workflow logic, not a universal Darktrace menu path. Use the exact settings documented for your installed release and receiving platform; do not substitute guessed endpoint addresses or field names.

Alert source configuration

Select the delivery route

1. Inspect the supported integration methods for your Darktrace deployment. Choose an event-delivery route only when the documentation confirms it is supported and your receiving system can authenticate it.
2. If a supported event-delivery route is unavailable, check for a documented retrieval interface. Establish its authentication, pagination and retrieval-window behaviour before scheduling requests.
3. Assign ownership of the integration credential. Store the credential in an approved secrets store, restrict its permissions and document how to replace it without losing delivery.
4. Capture a sanitised sample of the actual output. Preserve the original event reference, timestamp and source context where supplied, then identify which fields your receiver requires.

Expected result: You have a documented, authorised route from Darktrace to the receiver and a sample payload that the receiver can parse. Stop here if either is unconfirmed.

Compare the supported routes

These are conditional implementation patterns, not a claim that every Darktrace deployment includes both options.

Choose the route your deployment supports, not the route with the shortest setup screen. Both patterns need duplicate protection and visible failure handling. Neither replaces SOC ownership.

In your 2026 integration record, document the selected method, its permissions and the person accountable for changes. This makes release reviews and credential changes an operational task rather than a reconstruction exercise.

Event mapping and filtering

Define the case contract

1. Create a mapping document between the source payload and the receiving case. Use the logical fields below as your design contract; they are not Darktrace interface labels.
2. Preserve the original anomaly reference separately from the workflow’s delivery reference. A delivery retry must not become a new investigation simply because its transport identifier changed.
3. Translate source context into your organisation’s severity policy. Do not assume an anomaly score means the same thing as business impact or confirmed compromise.
4. Route malformed events to an exception queue with an owner. Do not silently discard a payload because a required field is absent.

Keep 2 timestamps in the case: event time and receipt time. They distinguish an old event delivered late from a newly observed event, without presenting a single ambiguous time to the analyst.

Apply an explicit alert policy

Choose which events create cases, which update existing cases and which remain recorded without paging an analyst. Write the reason for each exclusion. An exception should be explainable during a review.

For your 2026 policy review, involve the people who understand critical systems and business operations. A technically unusual event on a low-impact device and an event affecting an essential business service need different assessments; the source signal alone does not establish that distinction.

Expected result: A valid event becomes a consistent case record, while incomplete or excluded events remain visible through documented handling paths.

SOC routing and acknowledgement

Build the case-first sequence

1. Validate input. Check authentication and required fields before making changes in the receiving system. Record rejected deliveries without exposing credentials or unnecessary payload contents.
2. Check correlation. Look up the source reference in the workflow’s correlation store. If a case already exists, update it according to your policy rather than creating another.
3. Create or update. Write the case, assign the agreed SOC queue and store the relationship between the source reference and the case reference.
4. Notify the owner. Send the notification only after the case operation succeeds. Include a concise summary, priority, affected asset where available and the receiving system’s case reference.
5. Track acknowledgement. Use the receiving platform’s supported acknowledgement or ownership mechanism. Escalate unacknowledged cases according to your agreed operating procedure.

Use 1 stable correlation key for each source event. Where multiple source environments can produce overlapping identifiers, include the environment in that key rather than relying on the event identifier alone.

A notification channel is useful for visibility, but it is a poor substitute for an investigation record. Keep ownership, status and response notes in the case system instead of spreading them across messages.

Expected result: Each accepted source event maps to the correct case, and the assigned SOC queue can acknowledge it. Failed case creation produces an operational exception, not a misleading success notification.

Delivery testing and recovery

Test the entire hand-off

1. Submit an authorised test event through the selected route. Confirm the mapping, case queue, priority and notification against your written contract.
2. Resubmit the same event. Check that duplicate protection updates or recognises the existing case without opening another investigation.
3. Simulate an unavailable destination in a controlled test environment. Confirm that the workflow records the failure, retries according to policy and exposes events requiring intervention.
4. Restore delivery and replay the failed event. Check that recovery preserves correlation and does not create duplicate cases or repeated escalation messages.

Run 3 test scenarios before enabling production routing: normal delivery, duplicate delivery and destination failure. Test recovery as part of the failure scenario rather than treating a logged error as proof that recovery works.

Retries need boundaries. Define which failures are retryable, when retries stop and where failed events wait for review. Authentication failures require credential investigation; blindly repeating the same rejected request is not a recovery plan.

For your 2026 acceptance record, retain sanitised evidence of case creation, duplicate handling and recovery. Have the SOC owner confirm that the case contains enough information to begin triage.

Expected result: Normal delivery, repetition and interruption all have observable outcomes, with an accountable owner for exceptions.

Update an existing case when an anomaly changes

A second workflow is useful when your supported source interface exposes changes to an existing event. Do not enable this variant until you have confirmed what counts as an update and how that update is identified.

Match the update to the original source reference, retrieve the existing case and append the changed context. Preserve earlier observations rather than overwriting the investigation history.

Re-notify the SOC only when the change meets your escalation policy. A repeated payload should not trigger the same response as a material change in assessed business risk.

If an update refers to a closed case, apply an explicit reopening rule. Depending on your operating procedure, that means reopening the case, creating a linked investigation or sending the update for review. Do not let an integration choose silently.

Best for: Teams that receive meaningful event changes and need investigation continuity. The advantage is a single history; the constraint is that incorrect correlation or reopening rules can obscure separate investigations.

Troubleshooting

The receiver gets an event, but no case appears

Inspect validation and case-creation logs separately. Check required fields, destination permissions and queue identifiers. Route the failed event to the exception process, then replay it after fixing the underlying issue.

The same anomaly creates multiple cases

Check whether correlation uses the source event reference or a changing delivery identifier. Also inspect concurrent deliveries: the lookup and creation process needs protection against simultaneous requests creating separate cases.

Cases arrive, but nobody acknowledges them

Verify queue membership, ownership rules and the escalation path. Test the acknowledgement mechanism with the SOC team; a successful notification response proves delivery to a system, not acceptance by a person.

Scheduled retrieval misses events

Inspect pagination, saved cursors, timezone handling and retrieval windows. Use the source interface’s documented retrieval behaviour and retain the previous checkpoint until processing succeeds. Any deliberate overlap must pass through duplicate protection.

Alerts stop after a credential change

Check the active credential reference, permissions and receiver authentication configuration. Replace secrets through the approved process, test delivery and inspect the failed-event backlog before declaring the workflow restored.

Customize your workflow

Extend automation only after case creation and recovery work reliably. Add approved asset ownership, business-service context and escalation rules where those inputs are maintained and authorised for this purpose.

Keep notification automation separate from containment. Disabling an account, isolating a device or changing network access requires its own authority, safeguards and recovery procedure. An anomaly is a reason to assess activity, not automatic proof that disruption is justified.

CyberAgency Group offers managed cybersecurity and managed IT; use that combined scope to discuss who owns detection, remediation and business continuity. Define responsibilities explicitly rather than assuming that a monitoring arrangement includes every response action.

For executive oversight, the vCISO services guide covers an adjacent decision: how security priorities and accountability fit into the wider organisation.

FAQ

One last thing

Test for silence, not just successful delivery. A workflow can send notifications correctly and still leave cases unowned. Include an unacknowledged test case in your 2026 operating review and verify that the agreed escalation reaches an accountable person.

Related guides

• Cyber risk assessment providers for SMEs
• Microsoft 365 to Essential Eight compliance workflow
• Managed cloud connectivity providers in Australia