SIA DC03 alarm event format
SIA Format describes alarm messages exchanged by transmitters and receivers. Check the message structure, account identity, event mapping and acknowledgement behaviour.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Inherited check dated 10 September 2026. Supporting evidence for this inherited check has not been independently confirmed.
Recorded scope: The SIA public standards catalogue lists DC03 2017. This is an edition check, not a modem or receiver interoperability test.
Public SIA scope was reviewed; timing, frequencies, field grammar, checks, and event codes require the purchased normative standard.
On this page
Overview#
SIA DC03, commonly called the SIA Format, specifies digital communication between alarm transmitters and receivers. SIA's public page lists DC03 2017 and describes an open ended block format with variable length account and data sections, multi block expansion, transmission rules, interpretation, and interoperability objectives.[^sia dc03]
Scope#
DC03 is an event content and transmission format, not a modern secure network transport. It historically fits communicator to receiver paths and can also appear as payload content carried by IP alarm reporting products. When a product says “SIA,” determine whether it means DC03 content, DC09 IP transport, a vendor's subset, or merely a SIA event code vocabulary.
event source
│ account + event blocks + protocol checks
▼
communicator ───────────────> receiver
Developer data model#
Don't map a received event directly to a free form string. Preserve at least:
- protocol and edition;
- raw bounded message or protected evidence reference;
- account and receiver route as separate identifiers;
- event code and qualifier/condition;
- area/partition and zone/user/device references when present;
- occurrence time, receive time, and whether the timestamp came from the premises or receiver;
- block ordering and continuation state;
- integrity/check result, receiver response, and parser warnings;
- vendor extension namespace and original value.
Normalise into a canonical event only after retaining the source semantics. Unknown codes are valid evidence; they aren't permission to invent a nearest known meaning.
Parser requirements#
- Bound the total message, block count, account length, field count, and numeric conversions before allocating storage.
- Implement the purchased edition's exact timing, framing, character, error detection, and acknowledgement rules. Community summaries are insufficient for conformance.
- Treat incomplete multi block messages as incomplete. Never emit a fully qualified alarm from a prefix unless the site's policy explicitly defines a safe degraded mapping.
- Preserve leading zeroes and identifiers as strings where the standard treats them as identifiers.
- Make duplicate and retransmission handling idempotent at the receiver/automation boundary.
- Reject malformed data deterministically and record a sanitised reason; never feed raw control characters into logs or operator displays.
Security properties#
DC03's historical communication model doesn't itself provide modern peer authentication, authorisation, confidentiality, or replay protection. Error detection protects transmission integrity against some accidental corruption; it isn't a cryptographic authenticity check.
Use a protected, authenticated conduit where DC03 is carried over IP, isolate receiver interfaces, authorise each account to source relationship, and detect duplicates, impossible sequences, and event rate anomalies. If DC03 content is transported in DC09, apply DC09 security and retry controls as well; don't assume the inner format becomes secure by association.
Interoperability questions#
Record supported DC03 edition, event code set, optional fields, maximum lengths, multi block support, character/timing mode, receiver replies, restoration semantics, time zone rules, and vendor extensions. The SIA public description explicitly expects manufacturer to manufacturer resolution for incompatibilities and provides a standards subcommittee interpretation path.[^sia dc03]
Safety boundary#
Use synthetic events on a non dispatch receiver route. Parser tests must not dial or transmit to a production receiver. Panic, duress, hold up, fire, medical, and restore events require monitoring centre approval even in a nominal test account because automation rules may span accounts or receivers.
Primary source#
[^sia dc03]: Security Industry Association, DC03 2017, DCS SIA Format Standard, reviewed 25 August 2026.