Bottom line: Treat acknowledgment as an alarm-workflow transition, not as a deletion instruction. Confirm the event-history requirement independently before allowing an operator interface to describe an acknowledged alarm as erased.
\nAxis’s Event logger service says alarms are stored in a separate alarm log and also in the event log; acknowledgment removes an alarm from the alarm log while keeping it in the event log.
\nWhen an event matches both an ignore filter and an alarm filter, the documented outcome marks it as an alarm and stores it in the event log, overriding the ignore filter.
\nFor the documented alarm filters, omitting controller UUIDs applies the filter to all controllers, while supplied UUIDs limit elevation to events from those controllers.
\nDo not infer permanent retention, tamper resistance or a regulatory deletion outcome from acknowledgment behavior. Confirm the exact controller, service and software scope before applying this model. Avoid extending a filter to every controller merely to simplify a test, and do not use a real security incident as a disposable test event.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends accepting the alarm lifecycle and historical-event lifecycle as separate checks.
\nRetain sanitized filter definitions, controller identities, the test-input description and paired before/after records. Preserve acknowledgment time separately from event time. Have a reviewer locate the same historical record after the acknowledgment step instead of accepting a screenshot of an empty active-alarm list as the entire result.
\nFor the proposed overlap case, retain enough filter detail to explain why both matches were expected and which controllers were in scope. Do not claim a general retention period from that one exercise. Resolve any disagreement between active alarms, historical events and the operator’s display before adopting the workflow.
\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.
\n", "content_text": "Bottom line: Treat acknowledgment as an alarm-workflow transition, not as a deletion instruction. Confirm the event-history requirement independently before allowing an operator interface to describe an acknowledged alarm as erased.\nSource fact: documented behavior\nAxis’s Event logger service says alarms are stored in a separate alarm log and also in the event log; acknowledgment removes an alarm from the alarm log while keeping it in the event log.\nWhen an event matches both an ignore filter and an alarm filter, the documented outcome marks it as an alarm and stores it in the event log, overriding the ignore filter.\nFor the documented alarm filters, omitting controller UUIDs applies the filter to all controllers, while supplied UUIDs limit elevation to events from those controllers.\nWhat the source does not establish\nDo not infer permanent retention, tamper resistance or a regulatory deletion outcome from acknowledgment behavior. Confirm the exact controller, service and software scope before applying this model. Avoid extending a filter to every controller merely to simplify a test, and do not use a real security incident as a disposable test event.\nApplicability questions\n\nWhich interface presents active alarms and which retrieves historical events?\nDoes the operator’s acknowledge label accurately describe the intended operation?\nWhich exact controller identities should each alarm or ignore filter cover?\nWhat separate retention and deletion requirements govern the event history?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends accepting the alarm lifecycle and historical-event lifecycle as separate checks.\n\nDefine a harmless, identifiable test event in an authorized nonproduction or isolated commissioning scope. Record its expected controller identity and the intended filter match. Export or document the current filters before changing them. Specify the wording that the operator should see when acknowledging the test alarm, and keep data-retention policy outside that button’s assumed meaning.\nGenerate the approved test input and capture the active-alarm and historical-event views before acknowledgment. Acknowledge through the supported interface, then inspect both views again. Compare the same event identity rather than counting rows alone. Record a missing historical entry, an unexplained duplicate or a scope mismatch as an unresolved result requiring investigation.\nWhere filter precedence matters to the design, prepare a separate controlled case that deliberately matches both proposed filter classes. Keep its controller scope explicit. Compare the observed alarm and event records with the documented precedence. Restore the approved filters after the exercise and have the operator owner review both the interface wording and the resulting history.\n\nVerification and evidence\nRetain sanitized filter definitions, controller identities, the test-input description and paired before/after records. Preserve acknowledgment time separately from event time. Have a reviewer locate the same historical record after the acknowledgment step instead of accepting a screenshot of an empty active-alarm list as the entire result.\nFor the proposed overlap case, retain enough filter detail to explain why both matches were expected and which controllers were in scope. Do not claim a general retention period from that one exercise. Resolve any disagreement between active alarms, historical events and the operator’s display before adopting the workflow.\nOfficial references\n\nEvent logger service — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: Treat acknowledgment as an alarm-workflow transition, not as a deletion instruction. Confirm the event-history requirement independently before allowing an operator interface to describe an acknowledged alarm as erased.\n\n## Source fact: documented behavior\n\nAxis’s [Event logger service](https://developer.axis.com/vapix/physical-access-control/event-logger-service/) says alarms are stored in a separate alarm log and also in the event log; acknowledgment removes an alarm from the alarm log while keeping it in the event log.\n\nWhen an event matches both an ignore filter and an alarm filter, the documented outcome marks it as an alarm and stores it in the event log, overriding the ignore filter.\n\nFor the documented alarm filters, omitting controller UUIDs applies the filter to all controllers, while supplied UUIDs limit elevation to events from those controllers.\n\n## What the source does not establish\n\nDo not infer permanent retention, tamper resistance or a regulatory deletion outcome from acknowledgment behavior. Confirm the exact controller, service and software scope before applying this model. Avoid extending a filter to every controller merely to simplify a test, and do not use a real security incident as a disposable test event.\n\n## Applicability questions\n\n- Which interface presents active alarms and which retrieves historical events?\n\n- Does the operator’s acknowledge label accurately describe the intended operation?\n\n- Which exact controller identities should each alarm or ignore filter cover?\n\n- What separate retention and deletion requirements govern the event history?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends accepting the alarm lifecycle and historical-event lifecycle as separate checks.\n\n- Define a harmless, identifiable test event in an authorized nonproduction or isolated commissioning scope. Record its expected controller identity and the intended filter match. Export or document the current filters before changing them. Specify the wording that the operator should see when acknowledging the test alarm, and keep data-retention policy outside that button’s assumed meaning.\n\n- Generate the approved test input and capture the active-alarm and historical-event views before acknowledgment. Acknowledge through the supported interface, then inspect both views again. Compare the same event identity rather than counting rows alone. Record a missing historical entry, an unexplained duplicate or a scope mismatch as an unresolved result requiring investigation.\n\n- Where filter precedence matters to the design, prepare a separate controlled case that deliberately matches both proposed filter classes. Keep its controller scope explicit. Compare the observed alarm and event records with the documented precedence. Restore the approved filters after the exercise and have the operator owner review both the interface wording and the resulting history.\n\n## Verification and evidence\n\nRetain sanitized filter definitions, controller identities, the test-input description and paired before/after records. Preserve acknowledgment time separately from event time. Have a reviewer locate the same historical record after the acknowledgment step instead of accepting a screenshot of an empty active-alarm list as the entire result.\n\nFor the proposed overlap case, retain enough filter detail to explain why both matches were expected and which controllers were in scope. Do not claim a general retention period from that one exercise. Resolve any disagreement between active alarms, historical events and the operator’s display before adopting the workflow.\n\n## Official references\n\n- [Event logger service](https://developer.axis.com/vapix/physical-access-control/event-logger-service/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/", "url": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Access Control", "item": "https://update.dsesecurity.com/topic/access-control/" }, { "@type": "ListItem", "position": 3, "name": "Acknowledge Axis alarms without treating acknowledgment as event deletion", "item": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/#article", "identifier": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/", "url": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/", "headline": "Acknowledge Axis alarms without treating acknowledgment as event deletion", "description": "Keep Axis alarm acknowledgment separate from event-log deletion, and verify alarm-versus-ignore filter precedence with controlled test events.", "abstract": "Keep Axis alarm acknowledgment separate from event-log deletion, and verify alarm-versus-ignore filter precedence with controlled test events.", "articleBody": "Bottom line: Treat acknowledgment as an alarm-workflow transition, not as a deletion instruction. Confirm the event-history requirement independently before allowing an operator interface to describe an acknowledged alarm as erased.\nSource fact: documented behavior\nAxis’s Event logger service says alarms are stored in a separate alarm log and also in the event log; acknowledgment removes an alarm from the alarm log while keeping it in the event log.\nWhen an event matches both an ignore filter and an alarm filter, the documented outcome marks it as an alarm and stores it in the event log, overriding the ignore filter.\nFor the documented alarm filters, omitting controller UUIDs applies the filter to all controllers, while supplied UUIDs limit elevation to events from those controllers.\nWhat the source does not establish\nDo not infer permanent retention, tamper resistance or a regulatory deletion outcome from acknowledgment behavior. Confirm the exact controller, service and software scope before applying this model. Avoid extending a filter to every controller merely to simplify a test, and do not use a real security incident as a disposable test event.\nApplicability questions\n\nWhich interface presents active alarms and which retrieves historical events?\nDoes the operator’s acknowledge label accurately describe the intended operation?\nWhich exact controller identities should each alarm or ignore filter cover?\nWhat separate retention and deletion requirements govern the event history?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends accepting the alarm lifecycle and historical-event lifecycle as separate checks.\n\nDefine a harmless, identifiable test event in an authorized nonproduction or isolated commissioning scope. Record its expected controller identity and the intended filter match. Export or document the current filters before changing them. Specify the wording that the operator should see when acknowledging the test alarm, and keep data-retention policy outside that button’s assumed meaning.\nGenerate the approved test input and capture the active-alarm and historical-event views before acknowledgment. Acknowledge through the supported interface, then inspect both views again. Compare the same event identity rather than counting rows alone. Record a missing historical entry, an unexplained duplicate or a scope mismatch as an unresolved result requiring investigation.\nWhere filter precedence matters to the design, prepare a separate controlled case that deliberately matches both proposed filter classes. Keep its controller scope explicit. Compare the observed alarm and event records with the documented precedence. Restore the approved filters after the exercise and have the operator owner review both the interface wording and the resulting history.\n\nVerification and evidence\nRetain sanitized filter definitions, controller identities, the test-input description and paired before/after records. Preserve acknowledgment time separately from event time. Have a reviewer locate the same historical record after the acknowledgment step instead of accepting a screenshot of an empty active-alarm list as the entire result.\nFor the proposed overlap case, retain enough filter detail to explain why both matches were expected and which controllers were in scope. Do not claim a general retention period from that one exercise. Resolve any disagreement between active alarms, historical events and the operator’s display before adopting the workflow.\nOfficial references\n\nEvent logger service — Axis Communications; official VAPIX documentation.\n\nSource review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T17:41:31+00:00", "dateModified": "2026-10-29T17:41:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/acknowledge-axis-alarms-without-treating-acknowledgment-as-event-deletion/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Acknowledge Axis alarms without treating acknowledgment as event deletion" }, "articleSection": [ "Access Control", "IT" ], "keywords": [ "Access Control", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 546, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — Event logger service", "url": "https://developer.axis.com/vapix/physical-access-control/event-logger-service/" } } ] } }