What Should a Product Send to the SOC?

Almost every enterprise procurement specification contains the same clause: the product must send its own log and its action log to the organisation's syslog source. The clause is usually a single line, and because it is a single line it gets underestimated. Behind it sit six separate questions that have to be answered properly. This article is about those questions and their reasonable answers.

Why the Requirement Exists

The reason in one sentence: a system's records must also exist somewhere the people who run that system cannot change.

A product keeps its own audit trail in its own database. Those records may be correct, signed and protected by a hash chain. But to someone with full access to that database they all sit under one roof. This is precisely why audit exists: an organisation's own assessment of its own records is not accepted on its own.

The SOC, by definition, belongs to a different team, in most organisations sits in a separate authority domain, and its own platform guarantees retention and immutability. The moment an event lands there, protecting that record stops being the product's responsibility.

One distinction should not be skipped here: collecting logs and producing evidence are not the same thing. Forwarding to the SOC makes the record exist outside as well; showing that the record has not been altered internally is a separate job, and log management alone does not produce it. That is also why the anchor stream is treated separately in this article; delivering the anchor outside is the subject of its own article.

There is a second reason that is rarely discussed: correlation. The SOC can place a database side event on the same timeline as network, identity and endpoint events. An execution that looks harmless on its own takes on meaning next to an unusual login made in the same minute.

Three Streams That Must Not Be Confused

The phrase "its own log and its action log" in the specification is a deliberate distinction. A third one should be added, and the three are not technically alike.

Stream	Content	What losing it means
The product's own log	Startup, errors, service state, authorisation denials, failed logins	Tolerable; it is operational information
Action log	Request opened, approved, rejected, executed, masking decision, evidence downloaded	Not tolerable; this is evidence
Anchor	The digest of the chain so far, and its signature	Not tolerable

The critical difference: the action log and the anchor already sit in a table. The product's own log does not. That single difference forces two different delivery mechanisms, and the whole outage section below follows from it.

A fourth, small stream should be added: a heartbeat. A liveness signal sent at a fixed interval. Silence is the SOC's weakest point; when a source stops sending events, the SOC reads it as a quiet day. A heartbeat is the standard way of saying "this source is still up", and SOC teams expect it.

Which Format

Four options come up, and the differences between them are smaller than people assume.

• RFC 5424 syslog with a JSON body. The format modern collectors digest most easily. It maps freely onto the receiver's own schema.
• CEF. ArcSight in origin, widely adopted. Requires field mapping.
• LEEF. For QRadar. Worth keeping in scope because QRadar is common.
• Plain JSON. For organisations that write to a file and read it with their own agent.

The volume difference is worth making explicit here too: sending governance events and monitoring database activity are different jobs, and the load they place on a SOC is not comparable. We covered that distinction in a separate article.

In practice SOC teams tend to give the same answer: everyone gets along with syslog and JSON, both are well known; other formats parse fine too, but these two are the most practical. So the format debate is usually inflated. The genuinely distinguishing questions are transport and outage behaviour.

On transport there is one rule: UDP must not be the default. UDP drops a message that does not fit in a single packet and does not tell you it dropped it. The default should be TLS over TCP. If TLS is used, a server certificate that cannot be verified must cause the connection to be refused, never a silent fallback to plaintext.

What Happens While the Collector Is Down

This is the question that genuinely separates products, and it is rarely written in the specification. The collector goes into maintenance, the network drops, a certificate expires. What happened to three days of events?

There are two approaches in the field.

A disk queue. What classic log forwarders (rsyslog, syslog-ng) do. Events are written to disk and sent once the connection returns. This is the right method for components that hold no other copy of the data.

Replay from the source. This is the better choice for the action log and the anchor, because the event already sits in the audit table. The product keeps a single number recording how far it has sent; when the connection returns it reads from that number onwards, in order. If the collector is down for three days it sends those three days in sequence, and nothing is lost.

The second method has another side benefit. An audit trail table is append only and every row is linked to the one before it. Adding a "sent to SIEM" column makes that table updatable and weakens its strongest claim. Keeping a single progress counter requires no such thing.

There is also the duplication question, and the honest answer is that exactly once delivery is not possible over syslog. If the process crashes after sending but before recording progress, the same event goes out again. The right solution is not to try to prevent duplicates but to give every event a stable, unique identifier the SOC can deduplicate on. "At least once delivery with a stable event identifier" is the most honest commitment available here.

Finally: sending to the SIEM must never block the main workflow. If approving a request slows down because the collector is slow, the evidence layer has turned into a component that halts production. Delivery should run on a separate path and failures should be swallowed, but not silently: once consecutive failures cross a threshold, an alert has to be raised.

What Must Not Reach the SOC

Skip this section and the integration itself becomes a data leak path. In most organisations the SOC collector belongs to a different team, and sometimes to an external service provider.

• Query result data. Never. That the query ran, how many rows it returned and which columns were masked can go; the data itself cannot.
• Passwords, connection strings, keys and tokens. These should already be redacted in the audit trail; redaction must be applied a second time on the SIEM path. Relying on a single point is not enough here.
• The full text of the executed script. It should not go by default, because a script can contain business data. A digest of the script, the object names and the statement count go instead. An organisation should be able to turn the full text on, but that has to be a separate choice and its default has to be off.
• The contents of the evidence file. That the file was produced and who downloaded it can go; its contents cannot.

The Floor Under the Filter

It is legitimate for an organisation to narrow the scope; volume needs managing. But there is a real danger here that specifications almost never mention: an organisation can hide the events that count against it from the SOC. Filtering out emergency interventions, bypassed approval steps and disabled controls inverts the purpose of the integration.

In a sound design some events cannot be filtered. Emergency intervention, control weakening, authorisation denial and the anchor go out regardless of the threshold.

There is a subtler point still. Changing the filter is itself a control weakening event and should reach the SOC. But there is a trap: if it is sent after the change takes effect, a decision to "turn off the action stream" stays inside the stream it just closed and never reaches the SOC. So a filter change has to be announced using the configuration that was in force before the change was applied. Only then does "an organisation can narrow the scope but cannot hide that it did" actually hold.

Seven Questions When Evaluating a Product

If the single line in the specification is reduced to "do you send it", everyone says yes. These questions are what create the distinction.

1. Are the product's own log and its action log separate streams, or does everything flow through one channel?
2. What happens if the collector is down for three days? Is anything lost, and if so in which stream?
3. If the same event goes out twice, what does the SOC use to tell them apart?
4. Does the product's own workflow slow down while the collector is unreachable?
5. Who finds out when the connection breaks, and how?
6. Is a setting change that narrows the scope announced to the SOC, and with which configuration?
7. Can sensitive data appear inside the message that is sent, and which fields are redacted?

The first five questions show whether the integration carries evidence. The last two show whether it creates a new risk. If a product cannot answer both sides clearly, it satisfies the clause in the specification technically but not in purpose.