{ "api_version": "1", "kind": "dse_post_collection", "self": "https://update.dsesecurity.com/api/v1/posts/?topic=business-continuity", "home_page_url": "https://update.dsesecurity.com/", "total_items": 26, "total_pages": 2, "page": 1, "per_page": 20, "filters": { "q": null, "topic": "business-continuity", "format": null, "priority": null, "sort": "stream", "effective_sort": "stream" }, "links": { "self": "https://update.dsesecurity.com/api/v1/posts/?topic=business-continuity", "next": "https://update.dsesecurity.com/api/v1/posts/?topic=business-continuity&page=2" }, "items": [ { "id": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "slug": "physical-access-control-ot-segmentation-remote-access", "url": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access.md", "json": "https://update.dsesecurity.com/api/v1/posts/physical-access-control-ot-segmentation-remote-access/" }, "title": "Treat physical access control as OT: segment it, constrain remote access, preserve availability", "summary": "NIST explicitly includes physical access-control systems in OT and frames their security around mapped data flows, segmentation, controlled remote access, and availability.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:29:04+00:00", "modified_at": "2026-07-19T21:29:04+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 438, "potentially_affected": "Networked physical access-control servers, controllers, readers, management workstations, building-system integrations, cloud connections, and temporary or persistent vendor access.", "dse_recommendation": "Map access-system dependencies and required flows, build risk-based zones, limit remote access, and test security changes against door availability and emergency operations.", "primary_source": { "name": "NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security", "url": "https://csrc.nist.gov/pubs/sp/800/82/r3/final", "published_on": "2023-09-28", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Physical access control is within NIST’s OT scope

\n

Source fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.

\n

The OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.

\n\n

Segment from documented flows

\n

NIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.

\n

Remote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.

\n\n

Current-publication boundary

\n

Rev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.

\n\n

DSE architecture checklist

\n

DSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.

\n
    \n
  1. Inventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.
    2. \n
  2. Assign owners and criticality, including the consequence of each component or dependency being unavailable.
    3. \n
  3. Document normal, emergency, offline, update, backup, monitoring, and support data flows.
    4. \n
  4. Create zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.
    5. \n
  5. Remove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.
    6. \n
  6. Use strong authentication and encryption where supported, with compensating controls documented for legacy limitations.
    7. \n
  7. Test controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.
    8. \n
  8. Review the architecture after integration, cloud, identity, site, or vendor-support changes.
    9. \n
\n\n

Official references

\n", "content_text": "Physical access control is within NIST’s OT scope\nSource fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.\nThe OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.\n\nSegment from documented flows\nNIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.\nRemote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.\n\nCurrent-publication boundary\nRev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.\n\nDSE architecture checklist\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.\n\nInventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.\nAssign owners and criticality, including the consequence of each component or dependency being unavailable.\nDocument normal, emergency, offline, update, backup, monitoring, and support data flows.\nCreate zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.\nRemove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.\nUse strong authentication and encryption where supported, with compensating controls documented for legacy limitations.\nTest controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.\nReview the architecture after integration, cloud, identity, site, or vendor-support changes.\n\nOfficial references\n\nNIST SP 800-82 Rev. 3 — the current final OT scope and security guidance.\nGuide to Operational Technology Security — PACS architecture, availability, segmentation, and remote-access details.\nNIST Operational Technology Security publications — current final and draft status tracking.", "content_markdown": "## Physical access control is within NIST’s OT scope\n\nSource fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.\n\nThe OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.\n\n## Segment from documented flows\n\nNIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.\n\nRemote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.\n\n## Current-publication boundary\n\nRev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.\n\n## DSE architecture checklist\n\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.\n\n- Inventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.\n\n- Assign owners and criticality, including the consequence of each component or dependency being unavailable.\n\n- Document normal, emergency, offline, update, backup, monitoring, and support data flows.\n\n- Create zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.\n\n- Remove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.\n\n- Use strong authentication and encryption where supported, with compensating controls documented for legacy limitations.\n\n- Test controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.\n\n- Review the architecture after integration, cloud, identity, site, or vendor-support changes.\n\n## Official references\n\n- [NIST SP 800-82 Rev. 3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) — the current final OT scope and security guidance.\n\n- [Guide to Operational Technology Security](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf) — PACS architecture, availability, segmentation, and remote-access details.\n\n- [NIST Operational Technology Security publications](https://csrc.nist.gov/projects/operational-technology-security/publications) — current final and draft status tracking." }, { "id": "https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing/", "slug": "physical-security-ot-backup-restore-testing", "url": "https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing.md", "json": "https://update.dsesecurity.com/api/v1/posts/physical-security-ot-backup-restore-testing/" }, "title": "Back up physical-security controllers like OT: configurations, tools, licenses, spares, and restore tests", "summary": "NIST SP 1339 treats OT recovery as more than copying configuration files: tools, licenses, compatible spares, documentation, integrity, and restore tests all matter.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:29:04+00:00", "modified_at": "2026-07-19T21:29:04+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 468, "potentially_affected": "Physical-security controllers and related OT-like infrastructure whose recovery depends on configurations, firmware, software, licenses, engineering tools, diagrams, or spare hardware.", "dse_recommendation": "Connect backups to inventory and change management, protect redundant copies, preserve recovery dependencies, and prove restoration on nonproduction equipment.", "primary_source": { "name": "NIST SP 1339 — OT Backup Quick Start Guide", "url": "https://csrc.nist.gov/pubs/sp/1339/final", "published_on": "2026-06-17", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Recovery starts with inventory

\n

Source fact: NIST SP 1339 says effective OT backup management integrates backups into change management, creates them regularly, tests them, and reviews them during recovery exercises. Its prerequisites begin with identifying configuration-bearing or process-supporting devices, keeping the asset inventory current, and assigning mission criticality to set frequency, retention, and recovery order.

\n

The required recovery set extends beyond a single export. NIST lists program and configuration files, firmware, software applications, operating-system or virtual-machine images, license keys, vendor tools, support documentation, and other materials needed for redeployment. It also recommends compatible spare parts that can meet recovery objectives and reduce supply-chain delay.

\n\n

Protect useful, restorable copies

\n

Backup frequency, media, and storage location should reflect how often information changes, system type, and risk. NIST recommends redundant storage on site and off site, protection from unauthorized access or destruction, and integrity and availability mechanisms such as hashing, encryption, or write-once media. It distinguishes hot backups for immediate failover, warm backups for quicker recovery with updated data, and cold backups or spares that require rebuilding.

\n

Testing is functional. NIST calls for recurring restoration on nonproduction systems to validate media reliability, practice the procedure, and confirm the restored system works. Hashing can verify content integrity where feasible, while native engineering comparisons can be appropriate for OT assets. Lessons from tests should update procedures.

\n

Engineering documents provide another recovery layer. NIST lists items such as network and wiring diagrams, equipment specifications, configuration details, and other documents that support verification and troubleshooting.

\n\n

Applicability boundary

\n

SP 1339 is an OT quick-start guide with a manufacturing-sector context. Applying its approach to physical access controllers or other security infrastructure is DSE synthesis and should be limited to systems whose operational characteristics fit. Vendor-supported export and restore instructions still govern the product. Configuration backup also does not replace recorded-video retention, database protection, redundancy, or an exercised business-continuity plan.

\n\n

DSE recovery checklist

\n

DSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit.

\n
    \n
  1. Identify every component that holds configuration or is required to rebuild the service.
    2. \n
  2. Set recovery order, frequency, retention, and copy locations from criticality and change rate.
    3. \n
  3. Export after approved changes and retain exact firmware, installers, licenses, utilities, cables, keys, and manuals.
    4. \n
  4. Maintain protected onsite and offsite copies with inventory labels and integrity records.
    5. \n
  5. Keep compatible, tested spares for components whose replacement lead time exceeds the recovery objective.
    6. \n
  6. Restore onto nonproduction or spare equipment and test communications, doors, events, time, users, and monitoring.
    7. \n
  7. Verify hashes and compare restored configuration using supported native tools.
    8. \n
  8. Update runbooks, diagrams, inventories, and backup scope after each exercise or material change.
    9. \n
\n\n

Official references

\n", "content_text": "Recovery starts with inventory\nSource fact: NIST SP 1339 says effective OT backup management integrates backups into change management, creates them regularly, tests them, and reviews them during recovery exercises. Its prerequisites begin with identifying configuration-bearing or process-supporting devices, keeping the asset inventory current, and assigning mission criticality to set frequency, retention, and recovery order.\nThe required recovery set extends beyond a single export. NIST lists program and configuration files, firmware, software applications, operating-system or virtual-machine images, license keys, vendor tools, support documentation, and other materials needed for redeployment. It also recommends compatible spare parts that can meet recovery objectives and reduce supply-chain delay.\n\nProtect useful, restorable copies\nBackup frequency, media, and storage location should reflect how often information changes, system type, and risk. NIST recommends redundant storage on site and off site, protection from unauthorized access or destruction, and integrity and availability mechanisms such as hashing, encryption, or write-once media. It distinguishes hot backups for immediate failover, warm backups for quicker recovery with updated data, and cold backups or spares that require rebuilding.\nTesting is functional. NIST calls for recurring restoration on nonproduction systems to validate media reliability, practice the procedure, and confirm the restored system works. Hashing can verify content integrity where feasible, while native engineering comparisons can be appropriate for OT assets. Lessons from tests should update procedures.\nEngineering documents provide another recovery layer. NIST lists items such as network and wiring diagrams, equipment specifications, configuration details, and other documents that support verification and troubleshooting.\n\nApplicability boundary\nSP 1339 is an OT quick-start guide with a manufacturing-sector context. Applying its approach to physical access controllers or other security infrastructure is DSE synthesis and should be limited to systems whose operational characteristics fit. Vendor-supported export and restore instructions still govern the product. Configuration backup also does not replace recorded-video retention, database protection, redundancy, or an exercised business-continuity plan.\n\nDSE recovery checklist\nDSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit.\n\nIdentify every component that holds configuration or is required to rebuild the service.\nSet recovery order, frequency, retention, and copy locations from criticality and change rate.\nExport after approved changes and retain exact firmware, installers, licenses, utilities, cables, keys, and manuals.\nMaintain protected onsite and offsite copies with inventory labels and integrity records.\nKeep compatible, tested spares for components whose replacement lead time exceeds the recovery objective.\nRestore onto nonproduction or spare equipment and test communications, doors, events, time, users, and monitoring.\nVerify hashes and compare restored configuration using supported native tools.\nUpdate runbooks, diagrams, inventories, and backup scope after each exercise or material change.\n\nOfficial references\n\nNIST SP 1339 publication record — the official CSRC status, publication details, and download page.\nNIST SP 1339: OT Backup Quick Start Guide — the June 17, 2026 inventory, backup, dependency, integrity, restoration, and documentation guidance.", "content_markdown": "## Recovery starts with inventory\n\nSource fact: NIST SP 1339 says effective OT backup management integrates backups into change management, creates them regularly, tests them, and reviews them during recovery exercises. Its prerequisites begin with identifying configuration-bearing or process-supporting devices, keeping the asset inventory current, and assigning mission criticality to set frequency, retention, and recovery order.\n\nThe required recovery set extends beyond a single export. NIST lists program and configuration files, firmware, software applications, operating-system or virtual-machine images, license keys, vendor tools, support documentation, and other materials needed for redeployment. It also recommends compatible spare parts that can meet recovery objectives and reduce supply-chain delay.\n\n## Protect useful, restorable copies\n\nBackup frequency, media, and storage location should reflect how often information changes, system type, and risk. NIST recommends redundant storage on site and off site, protection from unauthorized access or destruction, and integrity and availability mechanisms such as hashing, encryption, or write-once media. It distinguishes hot backups for immediate failover, warm backups for quicker recovery with updated data, and cold backups or spares that require rebuilding.\n\nTesting is functional. NIST calls for recurring restoration on nonproduction systems to validate media reliability, practice the procedure, and confirm the restored system works. Hashing can verify content integrity where feasible, while native engineering comparisons can be appropriate for OT assets. Lessons from tests should update procedures.\n\nEngineering documents provide another recovery layer. NIST lists items such as network and wiring diagrams, equipment specifications, configuration details, and other documents that support verification and troubleshooting.\n\n## Applicability boundary\n\nSP 1339 is an OT quick-start guide with a manufacturing-sector context. Applying its approach to physical access controllers or other security infrastructure is DSE synthesis and should be limited to systems whose operational characteristics fit. Vendor-supported export and restore instructions still govern the product. Configuration backup also does not replace recorded-video retention, database protection, redundancy, or an exercised business-continuity plan.\n\n## DSE recovery checklist\n\nDSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit.\n\n- Identify every component that holds configuration or is required to rebuild the service.\n\n- Set recovery order, frequency, retention, and copy locations from criticality and change rate.\n\n- Export after approved changes and retain exact firmware, installers, licenses, utilities, cables, keys, and manuals.\n\n- Maintain protected onsite and offsite copies with inventory labels and integrity records.\n\n- Keep compatible, tested spares for components whose replacement lead time exceeds the recovery objective.\n\n- Restore onto nonproduction or spare equipment and test communications, doors, events, time, users, and monitoring.\n\n- Verify hashes and compare restored configuration using supported native tools.\n\n- Update runbooks, diagrams, inventories, and backup scope after each exercise or material change.\n\n## Official references\n\n- [NIST SP 1339 publication record](https://csrc.nist.gov/pubs/sp/1339/final) — the official CSRC status, publication details, and download page.\n\n- [NIST SP 1339: OT Backup Quick Start Guide](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1339.pdf) — the June 17, 2026 inventory, backup, dependency, integrity, restoration, and documentation guidance." }, { "id": "https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing/", "slug": "onvif-profile-g-edge-recording-acceptance-testing", "url": "https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing.md", "json": "https://update.dsesecurity.com/api/v1/posts/onvif-profile-g-edge-recording-acceptance-testing/" }, "title": "ONVIF Profile G acceptance testing for edge recording and retrieval", "summary": "Profile G standardizes important recording and retrieval interfaces, but a resilient edge-recording design still needs capacity, outage, recovery, and evidence tests.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:28:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 435, "potentially_affected": "Video systems using camera or encoder storage, recording-capable devices, NVRs, VMS clients, or edge recording as a primary recorder or network-outage safeguard.", "dse_recommendation": "Verify exact Profile G conformance and run controlled storage, outage, retrieval, and reintegration tests against the real camera, media, and VMS combination.", "primary_source": { "name": "ONVIF — Profile G", "url": "https://www.onvif.org/profiles/profile-g/", "published_on": null, "authority": "ONVIF" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

What Profile G covers

\n

Source fact: ONVIF Profile G is designed for IP-based video storage and retrieval. A conformant device, such as a network camera or encoder, can record video over the network or on the device itself. A conformant client, such as VMS software, can configure, request, and control recording from a Profile G device.

\n

ONVIF’s 2014 release announcement describes a broader recording workflow that includes on-board storage, search, retrieval, and media playback. The current profile page also identifies receipt of audio and metadata streams when the client supports those features. That conditional wording is important: a Profile G label alone does not establish that every client accepts audio or metadata.

\n

Profile G provides standardized interfaces, not a storage-service guarantee. It does not assign an SD-card endurance rating, calculate retention, promise uninterrupted capture for every outage, validate timestamps, or certify that a VMS will reconcile every edge recording after connectivity returns. Those outcomes depend on the exact device, media, client, configuration, clock source, network behavior, and supported features.

\n\n

Define the recovery use case

\n

First decide why edge storage exists. It may be the primary recording destination, a short network-failure buffer, or a secondary evidence source. Define the expected recording mode, event triggers, frame rate, bitrate, audio and metadata needs, retention target, and maximum anticipated outage. Use manufacturer endurance and compatibility information for the actual media rather than deriving capacity from Profile G.

\n

Conformance must be checked for both sides of the intended workflow and for their exact installed versions. A feature list should be reviewed before testing so a conditional function is not mistaken for a universal requirement.

\n\n

DSE acceptance checklist

\n

DSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence.

\n
    \n
  1. Verify the exact device and client versions in ONVIF’s registry and retain their feature documents.
    2. \n
  2. Confirm supported media, health monitoring, usable capacity, overwrite behavior, and time synchronization from current manufacturer guidance.
    3. \n
  3. Create known recordings and prove search, retrieval, playback, timestamps, and export from the client.
    4. \n
  4. Where required, confirm that audio and metadata survive the complete recording and retrieval path.
    5. \n
  5. Simulate an approved network interruption, keep it within the designed duration, and document device behavior.
    6. \n
  6. Restore connectivity and verify discovery, backlog availability, chronology, duplicates, gaps, and VMS reconciliation.
    7. \n
  7. Test full, removed, failed, or replaced media using safe procedures supported by the manufacturer.
    8. \n
  8. Record the tested limits and schedule periodic health and retrieval checks.
    9. \n
\n\n

Official references

\n", "content_text": "What Profile G covers\nSource fact: ONVIF Profile G is designed for IP-based video storage and retrieval. A conformant device, such as a network camera or encoder, can record video over the network or on the device itself. A conformant client, such as VMS software, can configure, request, and control recording from a Profile G device.\nONVIF’s 2014 release announcement describes a broader recording workflow that includes on-board storage, search, retrieval, and media playback. The current profile page also identifies receipt of audio and metadata streams when the client supports those features. That conditional wording is important: a Profile G label alone does not establish that every client accepts audio or metadata.\nProfile G provides standardized interfaces, not a storage-service guarantee. It does not assign an SD-card endurance rating, calculate retention, promise uninterrupted capture for every outage, validate timestamps, or certify that a VMS will reconcile every edge recording after connectivity returns. Those outcomes depend on the exact device, media, client, configuration, clock source, network behavior, and supported features.\n\nDefine the recovery use case\nFirst decide why edge storage exists. It may be the primary recording destination, a short network-failure buffer, or a secondary evidence source. Define the expected recording mode, event triggers, frame rate, bitrate, audio and metadata needs, retention target, and maximum anticipated outage. Use manufacturer endurance and compatibility information for the actual media rather than deriving capacity from Profile G.\nConformance must be checked for both sides of the intended workflow and for their exact installed versions. A feature list should be reviewed before testing so a conditional function is not mistaken for a universal requirement.\n\nDSE acceptance checklist\nDSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence.\n\nVerify the exact device and client versions in ONVIF’s registry and retain their feature documents.\nConfirm supported media, health monitoring, usable capacity, overwrite behavior, and time synchronization from current manufacturer guidance.\nCreate known recordings and prove search, retrieval, playback, timestamps, and export from the client.\nWhere required, confirm that audio and metadata survive the complete recording and retrieval path.\nSimulate an approved network interruption, keep it within the designed duration, and document device behavior.\nRestore connectivity and verify discovery, backlog availability, chronology, duplicates, gaps, and VMS reconciliation.\nTest full, removed, failed, or replaced media using safe procedures supported by the manufacturer.\nRecord the tested limits and schedule periodic health and retrieval checks.\n\nOfficial references\n\nProfile G — current device, client, recording, audio, and metadata scope.\nONVIF Releases Profile G for Video Storage and Recording — the July 2, 2014 storage, search, retrieval, and playback release scope.\nConformant Products — exact product and version verification.", "content_markdown": "## What Profile G covers\n\nSource fact: ONVIF Profile G is designed for IP-based video storage and retrieval. A conformant device, such as a network camera or encoder, can record video over the network or on the device itself. A conformant client, such as VMS software, can configure, request, and control recording from a Profile G device.\n\nONVIF’s 2014 release announcement describes a broader recording workflow that includes on-board storage, search, retrieval, and media playback. The current profile page also identifies receipt of audio and metadata streams when the client supports those features. That conditional wording is important: a Profile G label alone does not establish that every client accepts audio or metadata.\n\nProfile G provides standardized interfaces, not a storage-service guarantee. It does not assign an SD-card endurance rating, calculate retention, promise uninterrupted capture for every outage, validate timestamps, or certify that a VMS will reconcile every edge recording after connectivity returns. Those outcomes depend on the exact device, media, client, configuration, clock source, network behavior, and supported features.\n\n## Define the recovery use case\n\nFirst decide why edge storage exists. It may be the primary recording destination, a short network-failure buffer, or a secondary evidence source. Define the expected recording mode, event triggers, frame rate, bitrate, audio and metadata needs, retention target, and maximum anticipated outage. Use manufacturer endurance and compatibility information for the actual media rather than deriving capacity from Profile G.\n\nConformance must be checked for both sides of the intended workflow and for their exact installed versions. A feature list should be reviewed before testing so a conditional function is not mistaken for a universal requirement.\n\n## DSE acceptance checklist\n\nDSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence.\n\n- Verify the exact device and client versions in ONVIF’s registry and retain their feature documents.\n\n- Confirm supported media, health monitoring, usable capacity, overwrite behavior, and time synchronization from current manufacturer guidance.\n\n- Create known recordings and prove search, retrieval, playback, timestamps, and export from the client.\n\n- Where required, confirm that audio and metadata survive the complete recording and retrieval path.\n\n- Simulate an approved network interruption, keep it within the designed duration, and document device behavior.\n\n- Restore connectivity and verify discovery, backlog availability, chronology, duplicates, gaps, and VMS reconciliation.\n\n- Test full, removed, failed, or replaced media using safe procedures supported by the manufacturer.\n\n- Record the tested limits and schedule periodic health and retrieval checks.\n\n## Official references\n\n- [Profile G](https://www.onvif.org/profiles/profile-g/) — current device, client, recording, audio, and metadata scope.\n\n- [ONVIF Releases Profile G for Video Storage and Recording](https://www.onvif.org/pressrelease/onvif-releases-profile-g-for-video-storage-and-recording/) — the July 2, 2014 storage, search, retrieval, and playback release scope.\n\n- [Conformant Products](https://www.onvif.org/conformant-products/) — exact product and version verification." }, { "id": "https://update.dsesecurity.com/updates/axis-device-compromise-evidence-cleanup-playbook/", "slug": "axis-device-compromise-evidence-cleanup-playbook", "url": "https://update.dsesecurity.com/updates/axis-device-compromise-evidence-cleanup-playbook/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/axis-device-compromise-evidence-cleanup-playbook.md", "json": "https://update.dsesecurity.com/api/v1/posts/axis-device-compromise-evidence-cleanup-playbook/" }, "title": "Suspected Axis device compromise: preserve evidence before cleanup", "summary": "Axis places evidence collection between detection and cleanup and warns that changing or powering off a suspected device can destroy information needed for investigation.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:28:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 424, "potentially_affected": "AXIS OS devices on active or LTS tracks when unusual access, traffic, streaming, accounts, configuration, applications, or loss of video suggests possible compromise.", "dse_recommendation": "Preserve device and network evidence before factory default or firmware work, then use version-appropriate Axis cleanup guidance and monitor before return to service.", "primary_source": { "name": "Axis Communications — AXIS OS Forensics Guide", "url": "https://help.axis.com/en-US/axis-os-forensics-guide", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Axis defines a three-stage process

\n

Source fact: The AXIS OS Forensics Guide applies to AXIS OS products on active and long-term-support tracks. It organizes response into detection, evidence collection, and cleanup. That order is material: Axis warns that modifying or powering off a suspected device can destroy evidence.

\n

Axis lists indicators such as access from an unknown address, unauthorized network traffic or video streaming, unexpected file transfers, configuration changes, new accounts, lost video or audio, and unknown applications. An indicator requires investigation; it is not proof by itself that a device was compromised.

\n

The device server report contains health information, system details, configuration information, and logs. Axis identifies its downloadable archive as the primary resource for device forensic investigation. Audit logging was introduced in AXIS OS 12.7. The guide warns that a factory default clears logs held locally and recommends remote syslog to prevent that specific loss.

\n\n

Cleanup depends on device capability

\n

Axis describes factory default as the most efficient cleanup step for its devices after evidence is collected. For devices without signed OS and secure boot, Axis directs users to install the latest supported AXIS OS after factory default and monitor the device before reintroduction. For devices with signed OS and secure boot, Axis states that factory default returns the device to a guaranteed non-compromised state.

\n

Those are product-specific statements, not a complete enterprise incident-response plan. The guide does not replace legal preservation, organizational escalation, network forensics, credential response, or continuity planning. Containment and cleanup must also account for security coverage and any operational dependency.

\n\n

DSE response checklist

\n

DSE recommendation: This is DSE operational synthesis. Preserve evidence and follow the organization’s incident authority before changing the device.

\n
    \n
  1. Open an incident record and capture reporter, time, device identity, observed indicator, site, coverage, and business impact.
    2. \n
  2. Do not reboot, upgrade, reset, or install tools before the incident lead approves evidence collection.
    3. \n
  3. Preserve VMS, switch, firewall, DHCP, DNS, authentication, monitoring, and remote-syslog evidence around the event.
    4. \n
  4. Download the server report and collect available audit, system, access, certificate, application, and connection information.
    5. \n
  5. Hash and protect collected files under the organization’s evidence-handling procedure.
    6. \n
  6. Coordinate containment at an appropriate boundary without silently destroying coverage or evidence.
    7. \n
  7. Identify signed-OS and secure-boot support, then follow the current model-specific Axis cleanup instructions.
    8. \n
  8. Restore only known configuration, rotate affected credentials as authorized, validate video and events, and monitor before return.
    9. \n
\n\n

Official references

\n", "content_text": "Axis defines a three-stage process\nSource fact: The AXIS OS Forensics Guide applies to AXIS OS products on active and long-term-support tracks. It organizes response into detection, evidence collection, and cleanup. That order is material: Axis warns that modifying or powering off a suspected device can destroy evidence.\nAxis lists indicators such as access from an unknown address, unauthorized network traffic or video streaming, unexpected file transfers, configuration changes, new accounts, lost video or audio, and unknown applications. An indicator requires investigation; it is not proof by itself that a device was compromised.\nThe device server report contains health information, system details, configuration information, and logs. Axis identifies its downloadable archive as the primary resource for device forensic investigation. Audit logging was introduced in AXIS OS 12.7. The guide warns that a factory default clears logs held locally and recommends remote syslog to prevent that specific loss.\n\nCleanup depends on device capability\nAxis describes factory default as the most efficient cleanup step for its devices after evidence is collected. For devices without signed OS and secure boot, Axis directs users to install the latest supported AXIS OS after factory default and monitor the device before reintroduction. For devices with signed OS and secure boot, Axis states that factory default returns the device to a guaranteed non-compromised state.\nThose are product-specific statements, not a complete enterprise incident-response plan. The guide does not replace legal preservation, organizational escalation, network forensics, credential response, or continuity planning. Containment and cleanup must also account for security coverage and any operational dependency.\n\nDSE response checklist\nDSE recommendation: This is DSE operational synthesis. Preserve evidence and follow the organization’s incident authority before changing the device.\n\nOpen an incident record and capture reporter, time, device identity, observed indicator, site, coverage, and business impact.\nDo not reboot, upgrade, reset, or install tools before the incident lead approves evidence collection.\nPreserve VMS, switch, firewall, DHCP, DNS, authentication, monitoring, and remote-syslog evidence around the event.\nDownload the server report and collect available audit, system, access, certificate, application, and connection information.\nHash and protect collected files under the organization’s evidence-handling procedure.\nCoordinate containment at an appropriate boundary without silently destroying coverage or evidence.\nIdentify signed-OS and secure-boot support, then follow the current model-specific Axis cleanup instructions.\nRestore only known configuration, rotate affected credentials as authorized, validate video and events, and monitor before return.\n\nOfficial references\n\nAXIS OS Forensics Guide — indicators, evidence-preservation order, server reports, audit logs, and cleanup.\nAXIS OS Hardening Guide — current preventive controls and remote logging context.\nAxis Security Advisories — official vulnerability and remediation notices.", "content_markdown": "## Axis defines a three-stage process\n\nSource fact: The AXIS OS Forensics Guide applies to AXIS OS products on active and long-term-support tracks. It organizes response into detection, evidence collection, and cleanup. That order is material: Axis warns that modifying or powering off a suspected device can destroy evidence.\n\nAxis lists indicators such as access from an unknown address, unauthorized network traffic or video streaming, unexpected file transfers, configuration changes, new accounts, lost video or audio, and unknown applications. An indicator requires investigation; it is not proof by itself that a device was compromised.\n\nThe device server report contains health information, system details, configuration information, and logs. Axis identifies its downloadable archive as the primary resource for device forensic investigation. Audit logging was introduced in AXIS OS 12.7. The guide warns that a factory default clears logs held locally and recommends remote syslog to prevent that specific loss.\n\n## Cleanup depends on device capability\n\nAxis describes factory default as the most efficient cleanup step for its devices after evidence is collected. For devices without signed OS and secure boot, Axis directs users to install the latest supported AXIS OS after factory default and monitor the device before reintroduction. For devices with signed OS and secure boot, Axis states that factory default returns the device to a guaranteed non-compromised state.\n\nThose are product-specific statements, not a complete enterprise incident-response plan. The guide does not replace legal preservation, organizational escalation, network forensics, credential response, or continuity planning. Containment and cleanup must also account for security coverage and any operational dependency.\n\n## DSE response checklist\n\nDSE recommendation: This is DSE operational synthesis. Preserve evidence and follow the organization’s incident authority before changing the device.\n\n- Open an incident record and capture reporter, time, device identity, observed indicator, site, coverage, and business impact.\n\n- Do not reboot, upgrade, reset, or install tools before the incident lead approves evidence collection.\n\n- Preserve VMS, switch, firewall, DHCP, DNS, authentication, monitoring, and remote-syslog evidence around the event.\n\n- Download the server report and collect available audit, system, access, certificate, application, and connection information.\n\n- Hash and protect collected files under the organization’s evidence-handling procedure.\n\n- Coordinate containment at an appropriate boundary without silently destroying coverage or evidence.\n\n- Identify signed-OS and secure-boot support, then follow the current model-specific Axis cleanup instructions.\n\n- Restore only known configuration, rotate affected credentials as authorized, validate video and events, and monitor before return.\n\n## Official references\n\n- [AXIS OS Forensics Guide](https://help.axis.com/en-US/axis-os-forensics-guide) — indicators, evidence-preservation order, server reports, audit logs, and cleanup.\n\n- [AXIS OS Hardening Guide](https://help.axis.com/en-US/axis-os-hardening-guide) — current preventive controls and remote logging context.\n\n- [Axis Security Advisories](https://help.axis.com/en-US/security-advisories) — official vulnerability and remediation notices." }, { "id": "https://update.dsesecurity.com/updates/nist-media-sanitization-camera-recorder-storage/", "slug": "nist-media-sanitization-camera-recorder-storage", "url": "https://update.dsesecurity.com/updates/nist-media-sanitization-camera-recorder-storage/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/nist-media-sanitization-camera-recorder-storage.md", "json": "https://update.dsesecurity.com/api/v1/posts/nist-media-sanitization-camera-recorder-storage/" }, "title": "Retiring camera, recorder, and removable storage under NIST SP 800-88 Rev. 2", "summary": "NIST SP 800-88 Rev. 2 emphasizes a governed media-sanitization program, appropriate clear, purge, or destroy methods, and separate verification and validation.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:28:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 395, "potentially_affected": "Camera SD cards, recorder HDDs and SSDs, appliance flash, removable export media, virtual or cloud storage, and other information storage media leaving use or control.", "dse_recommendation": "Classify the stored information, select an approved method using current technical guidance, verify execution, validate residual risk, and retain disposition evidence.", "primary_source": { "name": "NIST SP 800-88 Rev. 2 — Guidelines for Media Sanitization", "url": "https://csrc.nist.gov/pubs/sp/800/88/r2/final", "published_on": "2025-09-26", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Rev. 2 is a program, not a wipe-command table

\n

Source fact: NIST SP 800-88 Rev. 2 defines media sanitization as making access to target data infeasible for a given level of effort. The revision shifts emphasis from media-specific command tables toward an enterprise program that protects sensitive information during reuse or disposal.

\n

NIST organizes the program around three methods: clear, purge, and destroy. Its July 2026 FAQ says policy should connect information classification to acceptable methods and define documentation, evidence, roles, training, tool configuration, maintenance, verification, and validation. Rev. 2 does not recommend a specific command for each product; it points organizations toward current standards and approved policy.

\n

The FAQ also rejects a common shortcut: a seven-pass overwrite is not required. NIST says legacy multi-pass practices provide little additional confidentiality for modern storage and can shorten flash-media life. Sanitizing the entire information-storage-media device is preferred because selected data can spill into overprovisioned areas, remapped bad blocks, or other locations outside a logical boundary.

\n\n

Verification and validation are different

\n

Verification checks whether the sanitization technique completed without technical errors or anomalies. Validation is the organizational decision that reviews that evidence against data sensitivity and accepts any residual confidentiality risk. Both are needed for sanitization assurance.

\n

Cryptographic erase is not automatically valid because a product used encryption. NIST lists prerequisites including adequate cryptographic strength, no prior sensitive plaintext outside the protected boundary, and permanent zeroization of the relevant keys. Cloud or virtual storage introduces additional service and key-management dependencies.

\n\n

DSE disposition checklist

\n

DSE recommendation: This is DSE operational synthesis. Confirm preservation obligations and approved techniques before changing media.

\n
    \n
  1. Inventory every storage location, including removable, embedded, replica, archive, cloud, and exported copies.
    2. \n
  2. Confirm that retention requirements, investigations, legal holds, and evidence-preservation needs permit disposition.
    3. \n
  3. Classify the information and determine whether media stays inside organizational control or leaves it.
    4. \n
  4. Select clear, purge, or destroy through approved policy, current industry guidance, and device-manufacturer capabilities.
    5. \n
  5. Prefer whole-media sanitization; document and approve any selective approach and its encrypted boundary.
    6. \n
  6. Verify that the technique completed successfully and retain logs or tool output.
    7. \n
  7. Have an authorized role validate effectiveness and accept residual risk.
    8. \n
  8. Record media identity, method, date, operator, verifier, validator, destination, exceptions, and certificate of sanitization.
    9. \n
\n\n

Official references

\n", "content_text": "Rev. 2 is a program, not a wipe-command table\nSource fact: NIST SP 800-88 Rev. 2 defines media sanitization as making access to target data infeasible for a given level of effort. The revision shifts emphasis from media-specific command tables toward an enterprise program that protects sensitive information during reuse or disposal.\nNIST organizes the program around three methods: clear, purge, and destroy. Its July 2026 FAQ says policy should connect information classification to acceptable methods and define documentation, evidence, roles, training, tool configuration, maintenance, verification, and validation. Rev. 2 does not recommend a specific command for each product; it points organizations toward current standards and approved policy.\nThe FAQ also rejects a common shortcut: a seven-pass overwrite is not required. NIST says legacy multi-pass practices provide little additional confidentiality for modern storage and can shorten flash-media life. Sanitizing the entire information-storage-media device is preferred because selected data can spill into overprovisioned areas, remapped bad blocks, or other locations outside a logical boundary.\n\nVerification and validation are different\nVerification checks whether the sanitization technique completed without technical errors or anomalies. Validation is the organizational decision that reviews that evidence against data sensitivity and accepts any residual confidentiality risk. Both are needed for sanitization assurance.\nCryptographic erase is not automatically valid because a product used encryption. NIST lists prerequisites including adequate cryptographic strength, no prior sensitive plaintext outside the protected boundary, and permanent zeroization of the relevant keys. Cloud or virtual storage introduces additional service and key-management dependencies.\n\nDSE disposition checklist\nDSE recommendation: This is DSE operational synthesis. Confirm preservation obligations and approved techniques before changing media.\n\nInventory every storage location, including removable, embedded, replica, archive, cloud, and exported copies.\nConfirm that retention requirements, investigations, legal holds, and evidence-preservation needs permit disposition.\nClassify the information and determine whether media stays inside organizational control or leaves it.\nSelect clear, purge, or destroy through approved policy, current industry guidance, and device-manufacturer capabilities.\nPrefer whole-media sanitization; document and approve any selective approach and its encrypted boundary.\nVerify that the technique completed successfully and retain logs or tool output.\nHave an authorized role validate effectiveness and accept residual risk.\nRecord media identity, method, date, operator, verifier, validator, destination, exceptions, and certificate of sanitization.\n\nOfficial references\n\nNIST SP 800-88 Rev. 2: Guidelines for Media Sanitization — the September 26, 2025 final publication.\nFrequently Asked Questions for NIST SP 800-88r2 — the July 16, 2026 program, method, overwrite, assurance, and cryptographic-erase clarifications.", "content_markdown": "## Rev. 2 is a program, not a wipe-command table\n\nSource fact: NIST SP 800-88 Rev. 2 defines media sanitization as making access to target data infeasible for a given level of effort. The revision shifts emphasis from media-specific command tables toward an enterprise program that protects sensitive information during reuse or disposal.\n\nNIST organizes the program around three methods: clear, purge, and destroy. Its July 2026 FAQ says policy should connect information classification to acceptable methods and define documentation, evidence, roles, training, tool configuration, maintenance, verification, and validation. Rev. 2 does not recommend a specific command for each product; it points organizations toward current standards and approved policy.\n\nThe FAQ also rejects a common shortcut: a seven-pass overwrite is not required. NIST says legacy multi-pass practices provide little additional confidentiality for modern storage and can shorten flash-media life. Sanitizing the entire information-storage-media device is preferred because selected data can spill into overprovisioned areas, remapped bad blocks, or other locations outside a logical boundary.\n\n## Verification and validation are different\n\nVerification checks whether the sanitization technique completed without technical errors or anomalies. Validation is the organizational decision that reviews that evidence against data sensitivity and accepts any residual confidentiality risk. Both are needed for sanitization assurance.\n\nCryptographic erase is not automatically valid because a product used encryption. NIST lists prerequisites including adequate cryptographic strength, no prior sensitive plaintext outside the protected boundary, and permanent zeroization of the relevant keys. Cloud or virtual storage introduces additional service and key-management dependencies.\n\n## DSE disposition checklist\n\nDSE recommendation: This is DSE operational synthesis. Confirm preservation obligations and approved techniques before changing media.\n\n- Inventory every storage location, including removable, embedded, replica, archive, cloud, and exported copies.\n\n- Confirm that retention requirements, investigations, legal holds, and evidence-preservation needs permit disposition.\n\n- Classify the information and determine whether media stays inside organizational control or leaves it.\n\n- Select clear, purge, or destroy through approved policy, current industry guidance, and device-manufacturer capabilities.\n\n- Prefer whole-media sanitization; document and approve any selective approach and its encrypted boundary.\n\n- Verify that the technique completed successfully and retain logs or tool output.\n\n- Have an authorized role validate effectiveness and accept residual risk.\n\n- Record media identity, method, date, operator, verifier, validator, destination, exceptions, and certificate of sanitization.\n\n## Official references\n\n- [NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final) — the September 26, 2025 final publication.\n\n- [Frequently Asked Questions for NIST SP 800-88r2](https://csrc.nist.gov/files/pubs/sp/800/88/r2/final/docs/sp800-88r2-faq.pdf) — the July 16, 2026 program, method, overwrite, assurance, and cryptographic-erase clarifications." }, { "id": "https://update.dsesecurity.com/updates/onedrive-known-folder-move-controlled-rollout/", "slug": "onedrive-known-folder-move-controlled-rollout", "url": "https://update.dsesecurity.com/updates/onedrive-known-folder-move-controlled-rollout/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/onedrive-known-folder-move-controlled-rollout.md", "json": "https://update.dsesecurity.com/api/v1/posts/onedrive-known-folder-move-controlled-rollout/" }, "title": "Move Windows known folders to OneDrive without creating an empty desktop", "summary": "OneDrive Known Folder Move can redirect familiar Windows folders to the cloud, but prior redirection, other tenants, unsupported files, storage, bandwidth, and sync health must be resolved first.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:28:15+00:00", "modified_at": "2026-07-19T21:28:15+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 457, "potentially_affected": "Windows users whose Desktop, Documents, Pictures, Screenshots, or Camera Roll data will move through the OneDrive sync app, including migrations from Folder Redirection or another tenant.", "dse_recommendation": "Inventory current folder locations and data, update OneDrive, test a small representative group, validate files and sync health, and expand within Microsoft rollout guidance.", "primary_source": { "name": "Microsoft Learn: Redirect and move Windows known folders to OneDrive", "url": "https://learn.microsoft.com/en-us/sharepoint/redirect-known-folders", "published_on": "2025-03-27", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source fact: what Microsoft documents

\n

OneDrive Known Folder Move redirects supported Windows folders such as Desktop, Documents, Pictures, Screenshots, and Camera Roll into the user’s OneDrive. Users continue working in familiar locations while the OneDrive sync app uploads the content and makes it available from other devices. Administrators can prompt users to move folders or silently redirect supported folders through Group Policy, Intune administrative templates, or documented registry policy.

\n

Microsoft recommends upgrading to the latest OneDrive build and rolling out slowly to control upload demand. For existing devices, Microsoft currently recommends limiting silent Known Folder Move deployment to 1,000 devices per day and 4,000 per week across Windows and macOS. For the prompt policy, Microsoft recommends no more than 5,000 devices per day and 20,000 per week.

\n

Existing Folder Redirection requires a transition process. Known Folder Move does not work when the user is syncing OneDrive files in SharePoint Server. If folders are already redirected to another organization’s OneDrive, redirecting immediately to the new tenant creates new folders and can leave the user viewing an empty desktop until data is migrated. Microsoft documents separate steps for local paths, file shares, and previous OneDrive redirection.

\n

Licensing and applicability

\n

The user needs an eligible OneDrive for work or school service, supported sync application, sufficient cloud storage, and supported Windows configuration. File names, paths, open files, policies, network proxies, tenant restrictions, unsupported content, and previous folder ownership can block migration. Syncing content to OneDrive improves service availability but is not a complete independent backup, legal retention, or offline recovery strategy.

\n

DSE recommendation: production-safe operational steps

\n
    \n
  1. Inventory each user’s current Desktop, Documents, and Pictures paths, prior Folder Redirection, tenant association, file count and size, storage quota, unsupported files, permissions, and sync errors.
    2. \n
  2. Define the supported transition for local folders, network shares, or another OneDrive tenant. Preserve authoritative source data until destination validation is complete.
    3. \n
  3. Update the OneDrive sync app and verify required Microsoft 365 network endpoints, disk capacity, user identity, and Files On-Demand behavior.
    4. \n
  4. Pilot representative users with large data sets, laptops, remote connections, specialized applications, multiple devices, and redirected folders.
    5. \n
  5. Validate folder contents, timestamps where important, application save paths, desktop appearance, synchronization, conflict handling, web access, new-device recovery, and user support.
    6. \n
  6. Throttle or schedule upload where required and expand within Microsoft’s current daily and weekly rollout guidance.
    7. \n
  7. Monitor sync health and storage continuously. Remove the source only after documented acceptance and the applicable retention period.
    8. \n
\n

DSE recommends communicating the visual changes and error-resolution path before policy assignment. If a user sees an empty folder, stop further moves for that cohort, preserve both source locations, identify tenant and redirection state, and reconcile files before continuing.

\n

Official reference

\n

Redirect and move Windows known folders to OneDrive — supported folders, policies, rollout rates, prior redirection, bandwidth, and migration behavior.

", "content_text": "Source fact: what Microsoft documents\nOneDrive Known Folder Move redirects supported Windows folders such as Desktop, Documents, Pictures, Screenshots, and Camera Roll into the user’s OneDrive. Users continue working in familiar locations while the OneDrive sync app uploads the content and makes it available from other devices. Administrators can prompt users to move folders or silently redirect supported folders through Group Policy, Intune administrative templates, or documented registry policy.\nMicrosoft recommends upgrading to the latest OneDrive build and rolling out slowly to control upload demand. For existing devices, Microsoft currently recommends limiting silent Known Folder Move deployment to 1,000 devices per day and 4,000 per week across Windows and macOS. For the prompt policy, Microsoft recommends no more than 5,000 devices per day and 20,000 per week.\nExisting Folder Redirection requires a transition process. Known Folder Move does not work when the user is syncing OneDrive files in SharePoint Server. If folders are already redirected to another organization’s OneDrive, redirecting immediately to the new tenant creates new folders and can leave the user viewing an empty desktop until data is migrated. Microsoft documents separate steps for local paths, file shares, and previous OneDrive redirection.\nLicensing and applicability\nThe user needs an eligible OneDrive for work or school service, supported sync application, sufficient cloud storage, and supported Windows configuration. File names, paths, open files, policies, network proxies, tenant restrictions, unsupported content, and previous folder ownership can block migration. Syncing content to OneDrive improves service availability but is not a complete independent backup, legal retention, or offline recovery strategy.\nDSE recommendation: production-safe operational steps\n\nInventory each user’s current Desktop, Documents, and Pictures paths, prior Folder Redirection, tenant association, file count and size, storage quota, unsupported files, permissions, and sync errors.\nDefine the supported transition for local folders, network shares, or another OneDrive tenant. Preserve authoritative source data until destination validation is complete.\nUpdate the OneDrive sync app and verify required Microsoft 365 network endpoints, disk capacity, user identity, and Files On-Demand behavior.\nPilot representative users with large data sets, laptops, remote connections, specialized applications, multiple devices, and redirected folders.\nValidate folder contents, timestamps where important, application save paths, desktop appearance, synchronization, conflict handling, web access, new-device recovery, and user support.\nThrottle or schedule upload where required and expand within Microsoft’s current daily and weekly rollout guidance.\nMonitor sync health and storage continuously. Remove the source only after documented acceptance and the applicable retention period.\n\nDSE recommends communicating the visual changes and error-resolution path before policy assignment. If a user sees an empty folder, stop further moves for that cohort, preserve both source locations, identify tenant and redirection state, and reconcile files before continuing.\nOfficial reference\nRedirect and move Windows known folders to OneDrive — supported folders, policies, rollout rates, prior redirection, bandwidth, and migration behavior.", "content_markdown": "## Source fact: what Microsoft documents\n\nOneDrive Known Folder Move redirects supported Windows folders such as Desktop, Documents, Pictures, Screenshots, and Camera Roll into the user’s OneDrive. Users continue working in familiar locations while the OneDrive sync app uploads the content and makes it available from other devices. Administrators can prompt users to move folders or silently redirect supported folders through Group Policy, Intune administrative templates, or documented registry policy.\n\nMicrosoft recommends upgrading to the latest OneDrive build and rolling out slowly to control upload demand. For existing devices, Microsoft currently recommends limiting silent Known Folder Move deployment to 1,000 devices per day and 4,000 per week across Windows and macOS. For the prompt policy, Microsoft recommends no more than 5,000 devices per day and 20,000 per week.\n\nExisting Folder Redirection requires a transition process. Known Folder Move does not work when the user is syncing OneDrive files in SharePoint Server. If folders are already redirected to another organization’s OneDrive, redirecting immediately to the new tenant creates new folders and can leave the user viewing an empty desktop until data is migrated. Microsoft documents separate steps for local paths, file shares, and previous OneDrive redirection.\n\n## Licensing and applicability\n\nThe user needs an eligible OneDrive for work or school service, supported sync application, sufficient cloud storage, and supported Windows configuration. File names, paths, open files, policies, network proxies, tenant restrictions, unsupported content, and previous folder ownership can block migration. Syncing content to OneDrive improves service availability but is not a complete independent backup, legal retention, or offline recovery strategy.\n\n## DSE recommendation: production-safe operational steps\n\n- Inventory each user’s current Desktop, Documents, and Pictures paths, prior Folder Redirection, tenant association, file count and size, storage quota, unsupported files, permissions, and sync errors.\n\n- Define the supported transition for local folders, network shares, or another OneDrive tenant. Preserve authoritative source data until destination validation is complete.\n\n- Update the OneDrive sync app and verify required Microsoft 365 network endpoints, disk capacity, user identity, and Files On-Demand behavior.\n\n- Pilot representative users with large data sets, laptops, remote connections, specialized applications, multiple devices, and redirected folders.\n\n- Validate folder contents, timestamps where important, application save paths, desktop appearance, synchronization, conflict handling, web access, new-device recovery, and user support.\n\n- Throttle or schedule upload where required and expand within Microsoft’s current daily and weekly rollout guidance.\n\n- Monitor sync health and storage continuously. Remove the source only after documented acceptance and the applicable retention period.\n\nDSE recommends communicating the visual changes and error-resolution path before policy assignment. If a user sees an empty folder, stop further moves for that cohort, preserve both source locations, identify tenant and redirection state, and reconcile files before continuing.\n\n## Official reference\n\n[Redirect and move Windows known folders to OneDrive](https://learn.microsoft.com/en-us/sharepoint/redirect-known-folders) — supported folders, policies, rollout rates, prior redirection, bandwidth, and migration behavior." }, { "id": "https://update.dsesecurity.com/updates/microsoft-365-service-health-message-center-operations/", "slug": "microsoft-365-service-health-message-center-operations", "url": "https://update.dsesecurity.com/updates/microsoft-365-service-health-message-center-operations/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-365-service-health-message-center-operations.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-365-service-health-message-center-operations/" }, "title": "Turn Microsoft 365 Service health and Message center into an owned operations process", "summary": "Service health reports active Microsoft 365 issues, while Message center reports planned changes and required actions. Both need named owners, triage criteria, tracked tasks, and an out-of-band status path.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:28:15+00:00", "modified_at": "2026-07-19T21:28:15+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 465, "potentially_affected": "Microsoft 365 organizations operating Exchange Online, Teams, SharePoint, OneDrive, Microsoft 365 Apps, Dynamics 365, or other services represented in tenant communications.", "dse_recommendation": "Assign primary and backup reviewers, subscribe to relevant communications, check tenant health before disruptive troubleshooting, convert actionable messages into owned tasks, and retain Message IDs and closure evidence.", "primary_source": { "name": "Microsoft Learn: How to check Microsoft 365 service health", "url": "https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwide", "published_on": "2026-02-09", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source fact: what Microsoft documents

\n

The Microsoft 365 admin center Service health page shows the state of cloud services and active issues. Microsoft distinguishes advisories, where a service remains available but has limited or intermittent impact, from incidents, where a service or major function is unavailable. The page can also show issues detected for the organization that require customer action.

\n

Microsoft directs administrators to the public service-status page and the Microsoft 365 status account when the tenant admin center cannot be reached. Planned maintenance is not shown in Service health; Microsoft documents Message center as the location for planned maintenance, upcoming changes, feature updates, retirements, privacy notices, and actions required to avoid disruption.

\n

Message center offers service, tag, state, timing, act-by, platform, impact, and relevance fields. Microsoft documents that major updates requiring action are communicated at least 30 days ahead and that Plan for change posts are intended to provide advance action guidance, while acknowledging that availability and relevance features vary. Messages can be shared, linked, synchronized to Planner, or retrieved through the service communications API.

\n

Permissions and applicability

\n

Microsoft 365 administrative roles determine who can view Service health and Message center. Some roles do not have Message center access; a Message center reader can be used without broader administration. Release status is available only for supported announcements and currently has limited service coverage. Government, sovereign, service-specific, mobile, API, Planner, and privacy-message behavior can differ. Relevance is a prioritization aid, not proof that a message has no impact.

\n

DSE recommendation: production-safe operational steps

\n
    \n
  1. Assign a primary reviewer, backup reviewer, escalation owner, and service owners for identity, messaging, collaboration, endpoint, security, and business applications.
    2. \n
  2. Grant the least-privileged read role and configure service preferences, weekly digest, major-update notices, and privacy notices for accountable shared mailboxes where supported.
    3. \n
  3. During an outage, record local symptoms and time, then check tenant Service health before making broad configuration changes. Preserve the incident or advisory identifier and updates.
    4. \n
  4. Maintain an out-of-band public-status path for cases where identity or the admin center is unavailable.
    5. \n
  5. Triage Message center by act-by date, user impact, admin impact, retirement, privacy, service usage, and local dependencies. Do not rely only on relevance.
    6. \n
  6. Create an owned task for each actionable message with Message ID, deadline, pilot, communication, rollback, validation, and closure evidence.
    7. \n
  7. Review open tasks at least weekly and reconcile completed work against the original message when Microsoft updates timing or scope.
    8. \n
\n

DSE recommends separating Microsoft service incidents from local changes in the incident record. Correlation does not prove causation. If no service issue is posted, continue local investigation and use the admin-center report-an-issue path where appropriate.

\n

Official references

\n", "content_text": "Source fact: what Microsoft documents\nThe Microsoft 365 admin center Service health page shows the state of cloud services and active issues. Microsoft distinguishes advisories, where a service remains available but has limited or intermittent impact, from incidents, where a service or major function is unavailable. The page can also show issues detected for the organization that require customer action.\nMicrosoft directs administrators to the public service-status page and the Microsoft 365 status account when the tenant admin center cannot be reached. Planned maintenance is not shown in Service health; Microsoft documents Message center as the location for planned maintenance, upcoming changes, feature updates, retirements, privacy notices, and actions required to avoid disruption.\nMessage center offers service, tag, state, timing, act-by, platform, impact, and relevance fields. Microsoft documents that major updates requiring action are communicated at least 30 days ahead and that Plan for change posts are intended to provide advance action guidance, while acknowledging that availability and relevance features vary. Messages can be shared, linked, synchronized to Planner, or retrieved through the service communications API.\nPermissions and applicability\nMicrosoft 365 administrative roles determine who can view Service health and Message center. Some roles do not have Message center access; a Message center reader can be used without broader administration. Release status is available only for supported announcements and currently has limited service coverage. Government, sovereign, service-specific, mobile, API, Planner, and privacy-message behavior can differ. Relevance is a prioritization aid, not proof that a message has no impact.\nDSE recommendation: production-safe operational steps\n\nAssign a primary reviewer, backup reviewer, escalation owner, and service owners for identity, messaging, collaboration, endpoint, security, and business applications.\nGrant the least-privileged read role and configure service preferences, weekly digest, major-update notices, and privacy notices for accountable shared mailboxes where supported.\nDuring an outage, record local symptoms and time, then check tenant Service health before making broad configuration changes. Preserve the incident or advisory identifier and updates.\nMaintain an out-of-band public-status path for cases where identity or the admin center is unavailable.\nTriage Message center by act-by date, user impact, admin impact, retirement, privacy, service usage, and local dependencies. Do not rely only on relevance.\nCreate an owned task for each actionable message with Message ID, deadline, pilot, communication, rollback, validation, and closure evidence.\nReview open tasks at least weekly and reconcile completed work against the original message when Microsoft updates timing or scope.\n\nDSE recommends separating Microsoft service incidents from local changes in the incident record. Correlation does not prove causation. If no service issue is posted, continue local investigation and use the admin-center report-an-issue path where appropriate.\nOfficial references\n\nHow to check Microsoft 365 service health — tenant health, incidents, advisories, customer actions, and out-of-band status.\nTrack new and changed features in the Microsoft 365 Message center — filters, categories, notifications, permissions, tasks, API, and change timing.", "content_markdown": "## Source fact: what Microsoft documents\n\nThe Microsoft 365 admin center Service health page shows the state of cloud services and active issues. Microsoft distinguishes advisories, where a service remains available but has limited or intermittent impact, from incidents, where a service or major function is unavailable. The page can also show issues detected for the organization that require customer action.\n\nMicrosoft directs administrators to the public service-status page and the Microsoft 365 status account when the tenant admin center cannot be reached. Planned maintenance is not shown in Service health; Microsoft documents Message center as the location for planned maintenance, upcoming changes, feature updates, retirements, privacy notices, and actions required to avoid disruption.\n\nMessage center offers service, tag, state, timing, act-by, platform, impact, and relevance fields. Microsoft documents that major updates requiring action are communicated at least 30 days ahead and that Plan for change posts are intended to provide advance action guidance, while acknowledging that availability and relevance features vary. Messages can be shared, linked, synchronized to Planner, or retrieved through the service communications API.\n\n## Permissions and applicability\n\nMicrosoft 365 administrative roles determine who can view Service health and Message center. Some roles do not have Message center access; a Message center reader can be used without broader administration. Release status is available only for supported announcements and currently has limited service coverage. Government, sovereign, service-specific, mobile, API, Planner, and privacy-message behavior can differ. Relevance is a prioritization aid, not proof that a message has no impact.\n\n## DSE recommendation: production-safe operational steps\n\n- Assign a primary reviewer, backup reviewer, escalation owner, and service owners for identity, messaging, collaboration, endpoint, security, and business applications.\n\n- Grant the least-privileged read role and configure service preferences, weekly digest, major-update notices, and privacy notices for accountable shared mailboxes where supported.\n\n- During an outage, record local symptoms and time, then check tenant Service health before making broad configuration changes. Preserve the incident or advisory identifier and updates.\n\n- Maintain an out-of-band public-status path for cases where identity or the admin center is unavailable.\n\n- Triage Message center by act-by date, user impact, admin impact, retirement, privacy, service usage, and local dependencies. Do not rely only on relevance.\n\n- Create an owned task for each actionable message with Message ID, deadline, pilot, communication, rollback, validation, and closure evidence.\n\n- Review open tasks at least weekly and reconcile completed work against the original message when Microsoft updates timing or scope.\n\nDSE recommends separating Microsoft service incidents from local changes in the incident record. Correlation does not prove causation. If no service issue is posted, continue local investigation and use the admin-center report-an-issue path where appropriate.\n\n## Official references\n\n- [How to check Microsoft 365 service health](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health?view=o365-worldwide) — tenant health, incidents, advisories, customer actions, and out-of-band status.\n\n- [Track new and changed features in the Microsoft 365 Message center](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/message-center?view=o365-worldwide) — filters, categories, notifications, permissions, tasks, API, and change timing." }, { "id": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "slug": "microsoft-entra-emergency-access-accounts-readiness", "url": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-entra-emergency-access-accounts-readiness/" }, "title": "Keep two emergency Microsoft Entra accounts ready before the tenant needs them", "summary": "Emergency access accounts provide a recovery path when normal administrators cannot sign in or activate a role. They must be independent, strongly protected, monitored, and tested without becoming everyday admin accounts.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:53+00:00", "modified_at": "2026-07-19T21:27:53+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 452, "potentially_affected": "Microsoft Entra tenants, especially organizations that use federation, Conditional Access, Privileged Identity Management, multifactor authentication, or a small administrator team.", "dse_recommendation": "Maintain at least two cloud-only emergency accounts, protect them with independent phishing-resistant credentials, exclude them from blocking access policies, alert on use, and validate them every 90 days.", "primary_source": { "name": "Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID", "url": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access", "published_on": "2026-06-05", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source fact: what Microsoft documents

\n

Microsoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency.

\n

The current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion.

\n

Microsoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification.

\n

Applicability and cautions

\n

These recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities.

\n

DSE recommendation: production-safe operational steps

\n
    \n
  1. Inventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions.
    2. \n
  2. Create at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail.
    3. \n
  3. Register independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian.
    4. \n
  4. Confirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address.
    5. \n
  5. Configure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review.
    6. \n
  6. Run a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes.
    7. \n
\n

DSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested.

\n

Official reference

\n

Manage emergency access accounts in Microsoft Entra ID — account design, authentication, Conditional Access, monitoring, and validation guidance.

", "content_text": "Source fact: what Microsoft documents\nMicrosoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency.\nThe current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion.\nMicrosoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification.\nApplicability and cautions\nThese recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities.\nDSE recommendation: production-safe operational steps\n\nInventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions.\nCreate at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail.\nRegister independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian.\nConfirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address.\nConfigure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review.\nRun a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes.\n\nDSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested.\nOfficial reference\nManage emergency access accounts in Microsoft Entra ID — account design, authentication, Conditional Access, monitoring, and validation guidance.", "content_markdown": "## Source fact: what Microsoft documents\n\nMicrosoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency.\n\nThe current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion.\n\nMicrosoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification.\n\n## Applicability and cautions\n\nThese recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities.\n\n## DSE recommendation: production-safe operational steps\n\n- Inventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions.\n\n- Create at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail.\n\n- Register independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian.\n\n- Confirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address.\n\n- Configure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review.\n\n- Run a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes.\n\nDSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested.\n\n## Official reference\n\n[Manage emergency access accounts in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) — account design, authentication, Conditional Access, monitoring, and validation guidance." }, { "id": "https://update.dsesecurity.com/updates/intune-bitlocker-recovery-first-deployment/", "slug": "intune-bitlocker-recovery-first-deployment", "url": "https://update.dsesecurity.com/updates/intune-bitlocker-recovery-first-deployment/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/intune-bitlocker-recovery-first-deployment.md", "json": "https://update.dsesecurity.com/api/v1/posts/intune-bitlocker-recovery-first-deployment/" }, "title": "Enable BitLocker with Intune only after recovery is proven", "summary": "Intune can deploy standard or silent BitLocker encryption, but production readiness depends on supported hardware, usable recovery-key escrow, policy compatibility, and removal of conflicting encryption software.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:53+00:00", "modified_at": "2026-07-19T21:27:53+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 433, "potentially_affected": "Supported Windows devices managed by Microsoft Intune, especially organizations planning silent encryption or migrating from third-party full-disk encryption.", "dse_recommendation": "Inventory encryption and hardware prerequisites, define restricted recovery access, verify key escrow and recovery on a pilot, remove conflicts, and expand only after reporting confirms success.", "primary_source": { "name": "Microsoft Learn: Encrypt Windows devices with BitLocker using Intune", "url": "https://learn.microsoft.com/en-us/intune/device-configuration/endpoint-security/encrypt-bitlocker-windows", "published_on": "2026-04-15", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source fact: what Microsoft documents

\n

Microsoft Intune supports standard BitLocker, where users can see and interact with prompts, and silent BitLocker, which can encrypt a managed device without user interaction or local administrative rights. Microsoft identifies Endpoint security > Disk encryption as the focused policy surface and provides an encryption report for device status and recovery-key management.

\n

For silent encryption, Microsoft documents supported Windows versions, Microsoft Entra join or hybrid join, TPM 1.2 or later, native UEFI, Secure Boot, and a configured Windows Recovery Environment. Silent enablement cannot require a TPM startup PIN or startup key because those require user interaction. Some Microsoft security-baseline settings can conflict by enabling those startup requirements.

\n

Microsoft warns that suppressing the warning for other disk-encryption software allows BitLocker to continue even when another product is present. The result can include data loss, instability, boot failures, and complex recovery. Microsoft therefore directs administrators to identify and safely remove third-party encryption before silent deployment and to pilot representative devices.

\n

Licensing and applicability

\n

Applicable Intune licensing and a Windows edition that supports BitLocker management are required. Some settings require a supported TPM. Windows 10 reached end of support on 2025-10-14; although it can remain enrolled in Intune, Microsoft does not guarantee continuing functionality. Hardware capability, modern standby, policy type, recovery configuration, and user privilege affect encryption behavior. Personal Data Encryption on Windows 11 is a separate file-level feature and is not a replacement for BitLocker.

\n

DSE recommendation: production-safe operational steps

\n
    \n
  1. Inventory Windows version and edition, join state, TPM, UEFI, Secure Boot, WinRE, modern-standby capability, current encryption, and every third-party encryption agent.
    2. \n
  2. Define the recovery-key escrow location, authorized retrieval roles, identity-verification process, audit review, and post-recovery key rotation before enabling encryption.
    3. \n
  3. Resolve duplicate BitLocker settings across Endpoint security, device configuration, security baselines, Group Policy, and scripts. Use one documented authority where possible.
    4. \n
  4. Select representative pilot devices, including older hardware, standard users, remote users, and devices with important applications.
    5. \n
  5. Verify key escrow before restart. Perform a controlled recovery test using the supported process, then confirm access and audit evidence.
    6. \n
  6. Deploy the intended standard or silent policy, monitor encryption and error reports, and validate boot, sign-in, application, update, and remote-support workflows.
    7. \n
  7. Expand in rings only after recovery and business-function exit criteria pass. Stop on unexplained missing keys, conflicting encryption, or boot failures.
    8. \n
\n

DSE recommends never using an encryption-status percentage as the only success measure. A production-safe result requires encrypted devices, retrievable keys, authorized recovery, healthy restarts, and a tested response when a user reaches the recovery screen.

\n

Official reference

\n

Encrypt Windows devices with BitLocker using Intune — policy types, silent-encryption prerequisites, conflicts, reporting, and recovery planning.

", "content_text": "Source fact: what Microsoft documents\nMicrosoft Intune supports standard BitLocker, where users can see and interact with prompts, and silent BitLocker, which can encrypt a managed device without user interaction or local administrative rights. Microsoft identifies Endpoint security > Disk encryption as the focused policy surface and provides an encryption report for device status and recovery-key management.\nFor silent encryption, Microsoft documents supported Windows versions, Microsoft Entra join or hybrid join, TPM 1.2 or later, native UEFI, Secure Boot, and a configured Windows Recovery Environment. Silent enablement cannot require a TPM startup PIN or startup key because those require user interaction. Some Microsoft security-baseline settings can conflict by enabling those startup requirements.\nMicrosoft warns that suppressing the warning for other disk-encryption software allows BitLocker to continue even when another product is present. The result can include data loss, instability, boot failures, and complex recovery. Microsoft therefore directs administrators to identify and safely remove third-party encryption before silent deployment and to pilot representative devices.\nLicensing and applicability\nApplicable Intune licensing and a Windows edition that supports BitLocker management are required. Some settings require a supported TPM. Windows 10 reached end of support on 2025-10-14; although it can remain enrolled in Intune, Microsoft does not guarantee continuing functionality. Hardware capability, modern standby, policy type, recovery configuration, and user privilege affect encryption behavior. Personal Data Encryption on Windows 11 is a separate file-level feature and is not a replacement for BitLocker.\nDSE recommendation: production-safe operational steps\n\nInventory Windows version and edition, join state, TPM, UEFI, Secure Boot, WinRE, modern-standby capability, current encryption, and every third-party encryption agent.\nDefine the recovery-key escrow location, authorized retrieval roles, identity-verification process, audit review, and post-recovery key rotation before enabling encryption.\nResolve duplicate BitLocker settings across Endpoint security, device configuration, security baselines, Group Policy, and scripts. Use one documented authority where possible.\nSelect representative pilot devices, including older hardware, standard users, remote users, and devices with important applications.\nVerify key escrow before restart. Perform a controlled recovery test using the supported process, then confirm access and audit evidence.\nDeploy the intended standard or silent policy, monitor encryption and error reports, and validate boot, sign-in, application, update, and remote-support workflows.\nExpand in rings only after recovery and business-function exit criteria pass. Stop on unexplained missing keys, conflicting encryption, or boot failures.\n\nDSE recommends never using an encryption-status percentage as the only success measure. A production-safe result requires encrypted devices, retrievable keys, authorized recovery, healthy restarts, and a tested response when a user reaches the recovery screen.\nOfficial reference\nEncrypt Windows devices with BitLocker using Intune — policy types, silent-encryption prerequisites, conflicts, reporting, and recovery planning.", "content_markdown": "## Source fact: what Microsoft documents\n\nMicrosoft Intune supports standard BitLocker, where users can see and interact with prompts, and silent BitLocker, which can encrypt a managed device without user interaction or local administrative rights. Microsoft identifies Endpoint security > Disk encryption as the focused policy surface and provides an encryption report for device status and recovery-key management.\n\nFor silent encryption, Microsoft documents supported Windows versions, Microsoft Entra join or hybrid join, TPM 1.2 or later, native UEFI, Secure Boot, and a configured Windows Recovery Environment. Silent enablement cannot require a TPM startup PIN or startup key because those require user interaction. Some Microsoft security-baseline settings can conflict by enabling those startup requirements.\n\nMicrosoft warns that suppressing the warning for other disk-encryption software allows BitLocker to continue even when another product is present. The result can include data loss, instability, boot failures, and complex recovery. Microsoft therefore directs administrators to identify and safely remove third-party encryption before silent deployment and to pilot representative devices.\n\n## Licensing and applicability\n\nApplicable Intune licensing and a Windows edition that supports BitLocker management are required. Some settings require a supported TPM. Windows 10 reached end of support on 2025-10-14; although it can remain enrolled in Intune, Microsoft does not guarantee continuing functionality. Hardware capability, modern standby, policy type, recovery configuration, and user privilege affect encryption behavior. Personal Data Encryption on Windows 11 is a separate file-level feature and is not a replacement for BitLocker.\n\n## DSE recommendation: production-safe operational steps\n\n- Inventory Windows version and edition, join state, TPM, UEFI, Secure Boot, WinRE, modern-standby capability, current encryption, and every third-party encryption agent.\n\n- Define the recovery-key escrow location, authorized retrieval roles, identity-verification process, audit review, and post-recovery key rotation before enabling encryption.\n\n- Resolve duplicate BitLocker settings across Endpoint security, device configuration, security baselines, Group Policy, and scripts. Use one documented authority where possible.\n\n- Select representative pilot devices, including older hardware, standard users, remote users, and devices with important applications.\n\n- Verify key escrow before restart. Perform a controlled recovery test using the supported process, then confirm access and audit evidence.\n\n- Deploy the intended standard or silent policy, monitor encryption and error reports, and validate boot, sign-in, application, update, and remote-support workflows.\n\n- Expand in rings only after recovery and business-function exit criteria pass. Stop on unexplained missing keys, conflicting encryption, or boot failures.\n\nDSE recommends never using an encryption-status percentage as the only success measure. A production-safe result requires encrypted devices, retrievable keys, authorized recovery, healthy restarts, and a tested response when a user reaches the recovery screen.\n\n## Official reference\n\n[Encrypt Windows devices with BitLocker using Intune](https://learn.microsoft.com/en-us/intune/device-configuration/endpoint-security/encrypt-bitlocker-windows) — policy types, silent-encryption prerequisites, conflicts, reporting, and recovery planning." }, { "id": "https://update.dsesecurity.com/updates/ddos-readiness-response-playbook/", "slug": "ddos-readiness-response-playbook", "url": "https://update.dsesecurity.com/updates/ddos-readiness-response-playbook/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/ddos-readiness-response-playbook.md", "json": "https://update.dsesecurity.com/api/v1/posts/ddos-readiness-response-playbook/" }, "title": "Prepare for DDoS before availability becomes an incident", "summary": "DDoS readiness requires prioritized public services, provider coverage and emergency contacts, observable baselines, upstream mitigation, exercised decisions, and validated recovery.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 423, "potentially_affected": "Organizations relying on public websites, APIs, remote access, DNS, email, voice, messaging, cloud services, internet circuits, hosting providers, CDNs, or other externally reachable services.", "dse_recommendation": "Rank public services, document dependencies and provider defenses, baseline traffic, define and exercise response, preserve evidence, and correct coverage or architecture gaps.", "primary_source": { "name": "CISA, FBI, and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks", "url": "https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf", "published_on": "2024-03-21", "authority": "Cybersecurity and Infrastructure Security Agency" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

A large distributed denial-of-service attack can exceed controls at the target because the unwanted traffic has already consumed an upstream resource. Preparation therefore depends on service priorities, architecture, providers, communication, and rehearsed decisions—not only a firewall rule created during the outage.

\n\n

Prepare with providers before the event

\n

Source fact: CISA, FBI, and MS-ISAC recommend identifying critical externally available assets and services and reviewing the organizational impact of their loss. Organizations should understand DDoS protections and coverage gaps offered by internet, cloud, hosting, content-delivery, and mitigation providers before an attack.

\n

Source fact: High availability, load balancing, colocation, and removal of single points of failure can improve continuity. The guidance also explains that large attacks may need to be stopped or diverted through upstream provider or specialized DDoS defenses before traffic reaches the local environment.

\n

Source fact: A response plan should cover attack identification and confirmation, mitigation, monitoring, recovery, roles, communication, and provider coordination. Possible indicators include sudden traffic increases, latency, service unavailability, and degraded communications, but monitoring and traffic analysis are needed to distinguish an attack from other failures.

\n\n

Build a service-specific playbook

\n

DSE recommendation: rank each public service using safety, operational, financial, legal, customer, and reputational impact. Diagram its DNS, address space, protocols, authentication, application dependencies, provider paths, capacity, regions, failover, and single points of failure.

\n
    \n
  1. Record ISP, cloud, hosting, CDN, DNS, application, security-provider, leadership, communications, and law-enforcement contacts appropriate to the organization.
    2. \n
  2. Document contracted protections, exclusions, protected addresses and protocols, activation method, authorization, expected telemetry, evidence needs, and support escalation.
    3. \n
  3. Baseline normal traffic, latency, error, resource, and availability patterns and define criteria for confirmation and incident declaration.
    4. \n
  4. Preapprove bounded filtering, rate limits, traffic diversion, scaling, alternate communication, and business-continuity options where technically appropriate.
    5. \n
  5. Define evidence collection, status updates, recovery validation, and after-action review.
    6. \n
\n\n

Exercise the real coordination path

\n

DSE recommendation: run a tabletop with providers and a safe technical validation where contracts and architecture permit. Confirm who can activate mitigation, make DNS or routing changes, accept user impact, communicate externally, and declare recovery. Verify contacts outside the affected network and preserve configuration, traffic summaries, timestamps, alerts, logs, and provider records.

\n\n

Applicability and limits

\n

DDoS attacks vary by volume, protocol, reflection method, and application behavior. Rate limits or blocking can harm legitimate users, local capacity may not absorb an upstream attack, and a CDN may not cover every protocol or origin. The publication is general guidance, not a guarantee. Current provider architecture and contract terms determine available actions.

\n\n

Official reference

\n

Understanding and Responding to Distributed Denial-of-Service Attacks — joint preparedness and response guidance.

\n
", "content_text": "A large distributed denial-of-service attack can exceed controls at the target because the unwanted traffic has already consumed an upstream resource. Preparation therefore depends on service priorities, architecture, providers, communication, and rehearsed decisions—not only a firewall rule created during the outage.\n\n Prepare with providers before the event\n Source fact: CISA, FBI, and MS-ISAC recommend identifying critical externally available assets and services and reviewing the organizational impact of their loss. Organizations should understand DDoS protections and coverage gaps offered by internet, cloud, hosting, content-delivery, and mitigation providers before an attack.\n Source fact: High availability, load balancing, colocation, and removal of single points of failure can improve continuity. The guidance also explains that large attacks may need to be stopped or diverted through upstream provider or specialized DDoS defenses before traffic reaches the local environment.\n Source fact: A response plan should cover attack identification and confirmation, mitigation, monitoring, recovery, roles, communication, and provider coordination. Possible indicators include sudden traffic increases, latency, service unavailability, and degraded communications, but monitoring and traffic analysis are needed to distinguish an attack from other failures.\n\n Build a service-specific playbook\n DSE recommendation: rank each public service using safety, operational, financial, legal, customer, and reputational impact. Diagram its DNS, address space, protocols, authentication, application dependencies, provider paths, capacity, regions, failover, and single points of failure.\n \n Record ISP, cloud, hosting, CDN, DNS, application, security-provider, leadership, communications, and law-enforcement contacts appropriate to the organization.\n Document contracted protections, exclusions, protected addresses and protocols, activation method, authorization, expected telemetry, evidence needs, and support escalation.\n Baseline normal traffic, latency, error, resource, and availability patterns and define criteria for confirmation and incident declaration.\n Preapprove bounded filtering, rate limits, traffic diversion, scaling, alternate communication, and business-continuity options where technically appropriate.\n Define evidence collection, status updates, recovery validation, and after-action review.\n \n\n Exercise the real coordination path\n DSE recommendation: run a tabletop with providers and a safe technical validation where contracts and architecture permit. Confirm who can activate mitigation, make DNS or routing changes, accept user impact, communicate externally, and declare recovery. Verify contacts outside the affected network and preserve configuration, traffic summaries, timestamps, alerts, logs, and provider records.\n\n Applicability and limits\n DDoS attacks vary by volume, protocol, reflection method, and application behavior. Rate limits or blocking can harm legitimate users, local capacity may not absorb an upstream attack, and a CDN may not cover every protocol or origin. The publication is general guidance, not a guarantee. Current provider architecture and contract terms determine available actions.\n\n Official reference\n Understanding and Responding to Distributed Denial-of-Service Attacks — joint preparedness and response guidance.", "content_markdown": "A large distributed denial-of-service attack can exceed controls at the target because the unwanted traffic has already consumed an upstream resource. Preparation therefore depends on service priorities, architecture, providers, communication, and rehearsed decisions—not only a firewall rule created during the outage.\n\n## Prepare with providers before the event\n\nSource fact: CISA, FBI, and MS-ISAC recommend identifying critical externally available assets and services and reviewing the organizational impact of their loss. Organizations should understand DDoS protections and coverage gaps offered by internet, cloud, hosting, content-delivery, and mitigation providers before an attack.\n\nSource fact: High availability, load balancing, colocation, and removal of single points of failure can improve continuity. The guidance also explains that large attacks may need to be stopped or diverted through upstream provider or specialized DDoS defenses before traffic reaches the local environment.\n\nSource fact: A response plan should cover attack identification and confirmation, mitigation, monitoring, recovery, roles, communication, and provider coordination. Possible indicators include sudden traffic increases, latency, service unavailability, and degraded communications, but monitoring and traffic analysis are needed to distinguish an attack from other failures.\n\n## Build a service-specific playbook\n\nDSE recommendation: rank each public service using safety, operational, financial, legal, customer, and reputational impact. Diagram its DNS, address space, protocols, authentication, application dependencies, provider paths, capacity, regions, failover, and single points of failure.\n\n- Record ISP, cloud, hosting, CDN, DNS, application, security-provider, leadership, communications, and law-enforcement contacts appropriate to the organization.\n\n- Document contracted protections, exclusions, protected addresses and protocols, activation method, authorization, expected telemetry, evidence needs, and support escalation.\n\n- Baseline normal traffic, latency, error, resource, and availability patterns and define criteria for confirmation and incident declaration.\n\n- Preapprove bounded filtering, rate limits, traffic diversion, scaling, alternate communication, and business-continuity options where technically appropriate.\n\n- Define evidence collection, status updates, recovery validation, and after-action review.\n\n## Exercise the real coordination path\n\nDSE recommendation: run a tabletop with providers and a safe technical validation where contracts and architecture permit. Confirm who can activate mitigation, make DNS or routing changes, accept user impact, communicate externally, and declare recovery. Verify contacts outside the affected network and preserve configuration, traffic summaries, timestamps, alerts, logs, and provider records.\n\n## Applicability and limits\n\nDDoS attacks vary by volume, protocol, reflection method, and application behavior. Rate limits or blocking can harm legitimate users, local capacity may not absorb an upstream attack, and a CDN may not cover every protocol or origin. The publication is general guidance, not a guarantee. Current provider architecture and contract terms determine available actions.\n\n## Official reference\n\n[Understanding and Responding to Distributed Denial-of-Service Attacks](https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf) — joint preparedness and response guidance." }, { "id": "https://update.dsesecurity.com/updates/cybersecurity-supply-chain-lifecycle-governance/", "slug": "cybersecurity-supply-chain-lifecycle-governance", "url": "https://update.dsesecurity.com/updates/cybersecurity-supply-chain-lifecycle-governance/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/cybersecurity-supply-chain-lifecycle-governance.md", "json": "https://update.dsesecurity.com/api/v1/posts/cybersecurity-supply-chain-lifecycle-governance/" }, "title": "Build cyber supply-chain risk management into the full product lifecycle", "summary": "Cyber supply-chain risk management connects enterprise governance, business processes, acquisition, supplier evidence, operating oversight, incident coordination, continuity, and secure exit.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 417, "potentially_affected": "Organizations acquiring or operating hardware, software, cloud services, managed services, data services, connected devices, components, or other technology with supplier dependencies.", "dse_recommendation": "Define tiered governance, map critical suppliers and sub-tier dependencies, require proportionate evidence, monitor lifecycle change, and plan transition and end-of-life treatment.", "primary_source": { "name": "NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices", "url": "https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final", "published_on": "2024-11-01", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

A supplier questionnaire at purchase time cannot manage a product whose ownership, components, access, vulnerabilities, hosting, support, or sub-tier dependencies change over years. Cyber supply-chain risk management is a lifecycle and organizational responsibility.

\n\n

What NIST includes in C-SCRM

\n

Source fact: NIST SP 800-161 Rev. 1 Update 1 addresses risks from products or services that may contain malicious functionality, be counterfeit, or remain vulnerable because of poor manufacturing or development practices. NIST also highlights reduced buyer visibility into how acquired technology is developed, integrated, deployed, supported, and protected.

\n

Source fact: NIST integrates cybersecurity supply-chain risk management with broader risk management at enterprise, mission or business-process, and operational levels. The publication covers C-SCRM strategy and implementation plans, policy, plans, and risk assessment for products and services. This structure makes procurement one phase of continuing risk management rather than the finish line.

\n\n

Scale diligence to business impact

\n

DSE recommendation: define which products and services enter the C-SCRM process and tier them by impact, access, data, privilege, connectivity, replaceability, concentration, safety, and continuity dependency. Apply stronger evidence and approval requirements to higher-impact tiers instead of sending every supplier the same unreviewed questionnaire.

\n
    \n
  1. Map critical suppliers, products, sub-tier dependencies, data and administrative access, hosting regions, integration paths, and lifecycle stage.
    2. \n
  2. Request evidence proportionate to risk, such as secure-development practices, component governance, vulnerability handling, update integrity, incident history, independent assessment, continuity, and support commitments.
    3. \n
  3. Where appropriate, put security responsibilities, incident notice, access control, logging, vulnerability remediation, update and support, audit evidence, business continuity, data return or destruction, and exit expectations into agreements.
    4. \n
  4. Assign owners to review changes in product architecture, components, ownership, support, access, data use, vulnerabilities, and material incidents.
    5. \n
  5. Plan alternatives and transition before end of support, contract termination, supplier failure, or unacceptable residual risk.
    6. \n
\n\n

Record decisions without inventing certainty

\n

DSE recommendation: distinguish supplier statements, self-attestations, independent assessments, certifications, customer testing, and observed operating evidence. Record unresolved questions and residual risk with the appropriate acceptance authority. A completed questionnaire, certificate, or software bill of materials informs a decision but does not prove that a supplier or product is free of compromise or vulnerability.

\n\n

Applicability and limits

\n

NIST’s publication is comprehensive and federal-oriented, so organizations must tailor it. It does not produce a binary safe-vendor result and does not replace legal, procurement, sanctions, export, privacy, sector, insurance, accessibility, or contract review. Some evidence may be unavailable or sensitive; the organization must decide whether compensating controls, acceptance, transfer, avoidance, or another supplier is appropriate.

\n\n

Official reference

\n

NIST SP 800-161 Rev. 1 Update 1 — lifecycle cybersecurity supply-chain risk-management practices.

\n
", "content_text": "A supplier questionnaire at purchase time cannot manage a product whose ownership, components, access, vulnerabilities, hosting, support, or sub-tier dependencies change over years. Cyber supply-chain risk management is a lifecycle and organizational responsibility.\n\n What NIST includes in C-SCRM\n Source fact: NIST SP 800-161 Rev. 1 Update 1 addresses risks from products or services that may contain malicious functionality, be counterfeit, or remain vulnerable because of poor manufacturing or development practices. NIST also highlights reduced buyer visibility into how acquired technology is developed, integrated, deployed, supported, and protected.\n Source fact: NIST integrates cybersecurity supply-chain risk management with broader risk management at enterprise, mission or business-process, and operational levels. The publication covers C-SCRM strategy and implementation plans, policy, plans, and risk assessment for products and services. This structure makes procurement one phase of continuing risk management rather than the finish line.\n\n Scale diligence to business impact\n DSE recommendation: define which products and services enter the C-SCRM process and tier them by impact, access, data, privilege, connectivity, replaceability, concentration, safety, and continuity dependency. Apply stronger evidence and approval requirements to higher-impact tiers instead of sending every supplier the same unreviewed questionnaire.\n \n Map critical suppliers, products, sub-tier dependencies, data and administrative access, hosting regions, integration paths, and lifecycle stage.\n Request evidence proportionate to risk, such as secure-development practices, component governance, vulnerability handling, update integrity, incident history, independent assessment, continuity, and support commitments.\n Where appropriate, put security responsibilities, incident notice, access control, logging, vulnerability remediation, update and support, audit evidence, business continuity, data return or destruction, and exit expectations into agreements.\n Assign owners to review changes in product architecture, components, ownership, support, access, data use, vulnerabilities, and material incidents.\n Plan alternatives and transition before end of support, contract termination, supplier failure, or unacceptable residual risk.\n \n\n Record decisions without inventing certainty\n DSE recommendation: distinguish supplier statements, self-attestations, independent assessments, certifications, customer testing, and observed operating evidence. Record unresolved questions and residual risk with the appropriate acceptance authority. A completed questionnaire, certificate, or software bill of materials informs a decision but does not prove that a supplier or product is free of compromise or vulnerability.\n\n Applicability and limits\n NIST’s publication is comprehensive and federal-oriented, so organizations must tailor it. It does not produce a binary safe-vendor result and does not replace legal, procurement, sanctions, export, privacy, sector, insurance, accessibility, or contract review. Some evidence may be unavailable or sensitive; the organization must decide whether compensating controls, acceptance, transfer, avoidance, or another supplier is appropriate.\n\n Official reference\n NIST SP 800-161 Rev. 1 Update 1 — lifecycle cybersecurity supply-chain risk-management practices.", "content_markdown": "A supplier questionnaire at purchase time cannot manage a product whose ownership, components, access, vulnerabilities, hosting, support, or sub-tier dependencies change over years. Cyber supply-chain risk management is a lifecycle and organizational responsibility.\n\n## What NIST includes in C-SCRM\n\nSource fact: NIST SP 800-161 Rev. 1 Update 1 addresses risks from products or services that may contain malicious functionality, be counterfeit, or remain vulnerable because of poor manufacturing or development practices. NIST also highlights reduced buyer visibility into how acquired technology is developed, integrated, deployed, supported, and protected.\n\nSource fact: NIST integrates cybersecurity supply-chain risk management with broader risk management at enterprise, mission or business-process, and operational levels. The publication covers C-SCRM strategy and implementation plans, policy, plans, and risk assessment for products and services. This structure makes procurement one phase of continuing risk management rather than the finish line.\n\n## Scale diligence to business impact\n\nDSE recommendation: define which products and services enter the C-SCRM process and tier them by impact, access, data, privilege, connectivity, replaceability, concentration, safety, and continuity dependency. Apply stronger evidence and approval requirements to higher-impact tiers instead of sending every supplier the same unreviewed questionnaire.\n\n- Map critical suppliers, products, sub-tier dependencies, data and administrative access, hosting regions, integration paths, and lifecycle stage.\n\n- Request evidence proportionate to risk, such as secure-development practices, component governance, vulnerability handling, update integrity, incident history, independent assessment, continuity, and support commitments.\n\n- Where appropriate, put security responsibilities, incident notice, access control, logging, vulnerability remediation, update and support, audit evidence, business continuity, data return or destruction, and exit expectations into agreements.\n\n- Assign owners to review changes in product architecture, components, ownership, support, access, data use, vulnerabilities, and material incidents.\n\n- Plan alternatives and transition before end of support, contract termination, supplier failure, or unacceptable residual risk.\n\n## Record decisions without inventing certainty\n\nDSE recommendation: distinguish supplier statements, self-attestations, independent assessments, certifications, customer testing, and observed operating evidence. Record unresolved questions and residual risk with the appropriate acceptance authority. A completed questionnaire, certificate, or software bill of materials informs a decision but does not prove that a supplier or product is free of compromise or vulnerability.\n\n## Applicability and limits\n\nNIST’s publication is comprehensive and federal-oriented, so organizations must tailor it. It does not produce a binary safe-vendor result and does not replace legal, procurement, sanctions, export, privacy, sector, insurance, accessibility, or contract review. Some evidence may be unavailable or sensitive; the organization must decide whether compensating controls, acceptance, transfer, avoidance, or another supplier is appropriate.\n\n## Official reference\n\n[NIST SP 800-161 Rev. 1 Update 1](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final) — lifecycle cybersecurity supply-chain risk-management practices." }, { "id": "https://update.dsesecurity.com/updates/business-data-breach-response-sequence/", "slug": "business-data-breach-response-sequence", "url": "https://update.dsesecurity.com/updates/business-data-breach-response-sequence/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/business-data-breach-response-sequence.md", "json": "https://update.dsesecurity.com/api/v1/posts/business-data-breach-response-sequence/" }, "title": "Data breach response: coordinate containment, investigation, communication, and notification", "summary": "FTC guidance connects immediate operational security, forensic preservation, scope determination, corrective action, accurate communication, and fact-specific legal notification decisions.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 471, "potentially_affected": "U.S. organizations that store or process employee, customer, patient, financial, identity, authentication, or other sensitive personal information.", "dse_recommendation": "Activate qualified response resources, stop additional loss without destroying evidence, determine scope, remediate safely, document facts, and have counsel evaluate notification duties.", "primary_source": { "name": "Federal Trade Commission: Data Breach Response — A Guide for Business", "url": "https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business", "published_on": null, "authority": "Federal Trade Commission" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

A suspected data breach creates pressure to shut systems down, reassure customers, and announce an answer. Acting without forensic, legal, technical, and communications coordination can destroy evidence, leave the cause active, or produce statements that are incomplete or misleading.

\n\n

What the FTC guide establishes

\n

Source fact: The Federal Trade Commission organizes its business guidance around securing operations and notifying appropriate parties. It recommends mobilizing a response team that can include forensics, legal, information security, IT, operations, human resources, communications, management, and other functions appropriate to the organization.

\n

Source fact: The FTC advises moving quickly to stop additional loss, determine the source and scope, identify affected information and people, preserve evidence, correct vulnerabilities, document the investigation, and communicate accurately. It warns organizations not to turn affected machines off before forensic experts advise because powering down can affect evidence.

\n

Source fact: Notification duties vary. The FTC notes state and federal requirements and additional rules that may apply based on the information and organization. It advises consultation with counsel and coordination with law enforcement where appropriate.

\n\n

Coordinate overlapping response workstreams

\n

DSE recommendation: use the organization’s approved plan and activate qualified internal and external resources. Engage counsel and any insurer promptly when required by law, policy, or contract while qualified responders preserve evidence and contain harm. There is no universal sequence: legal, forensic, operational, safety, law-enforcement, insurer, vendor, and notification work can overlap, and their order depends on the facts and applicable obligations.

\n \n\n

Communicate facts without creating more harm

\n

DSE recommendation: designate an approved spokesperson and maintain one reviewed fact record. Explain what is known, what information was involved, what the organization has done, what affected people can do, and where updates will appear when counsel determines communication is appropriate. Do not speculate, minimize confirmed impact, disclose details that increase risk, or promise a result the investigation cannot support.

\n\n

Applicability and limits

\n

The FTC publication is general U.S. business guidance, not legal advice or a complete notification-law matrix. Requirements change and depend on jurisdiction, sector, data, contracts, insurer terms, and facts. This article intentionally provides no universal deadline or fixed response sequence. Organizations outside the United States need guidance for their applicable jurisdictions.

\n\n

Official reference

\n

Data Breach Response: A Guide for Business — FTC operational and notification considerations.

\n
", "content_text": "A suspected data breach creates pressure to shut systems down, reassure customers, and announce an answer. Acting without forensic, legal, technical, and communications coordination can destroy evidence, leave the cause active, or produce statements that are incomplete or misleading.\n\n What the FTC guide establishes\n Source fact: The Federal Trade Commission organizes its business guidance around securing operations and notifying appropriate parties. It recommends mobilizing a response team that can include forensics, legal, information security, IT, operations, human resources, communications, management, and other functions appropriate to the organization.\n Source fact: The FTC advises moving quickly to stop additional loss, determine the source and scope, identify affected information and people, preserve evidence, correct vulnerabilities, document the investigation, and communicate accurately. It warns organizations not to turn affected machines off before forensic experts advise because powering down can affect evidence.\n Source fact: Notification duties vary. The FTC notes state and federal requirements and additional rules that may apply based on the information and organization. It advises consultation with counsel and coordination with law enforcement where appropriate.\n\n Coordinate overlapping response workstreams\n DSE recommendation: use the organization’s approved plan and activate qualified internal and external resources. Engage counsel and any insurer promptly when required by law, policy, or contract while qualified responders preserve evidence and contain harm. There is no universal sequence: legal, forensic, operational, safety, law-enforcement, insurer, vendor, and notification work can overlap, and their order depends on the facts and applicable obligations.\n \n Protect people and essential operations, stop additional data loss, and preserve volatile and forensic evidence under qualified direction.\n Determine the entry path, duration, systems, identities, persistence, data types, affected individuals or organizations, and remaining exposure.\n Secure physical and digital access, compromised credentials, exposed information, affected integrations, and vulnerable systems without assuming the first containment action removed the actor.\n Implement and validate corrective actions, clean restoration, monitoring, and the intended business transaction.\n Document known facts, uncertainty, evidence, decisions, timestamps, scope, communications, and unresolved risk.\n Have counsel determine required notices and timing; coordinate clear communications and practical affected-person guidance.\n \n\n Communicate facts without creating more harm\n DSE recommendation: designate an approved spokesperson and maintain one reviewed fact record. Explain what is known, what information was involved, what the organization has done, what affected people can do, and where updates will appear when counsel determines communication is appropriate. Do not speculate, minimize confirmed impact, disclose details that increase risk, or promise a result the investigation cannot support.\n\n Applicability and limits\n The FTC publication is general U.S. business guidance, not legal advice or a complete notification-law matrix. Requirements change and depend on jurisdiction, sector, data, contracts, insurer terms, and facts. This article intentionally provides no universal deadline or fixed response sequence. Organizations outside the United States need guidance for their applicable jurisdictions.\n\n Official reference\n Data Breach Response: A Guide for Business — FTC operational and notification considerations.", "content_markdown": "A suspected data breach creates pressure to shut systems down, reassure customers, and announce an answer. Acting without forensic, legal, technical, and communications coordination can destroy evidence, leave the cause active, or produce statements that are incomplete or misleading.\n\n## What the FTC guide establishes\n\nSource fact: The Federal Trade Commission organizes its business guidance around securing operations and notifying appropriate parties. It recommends mobilizing a response team that can include forensics, legal, information security, IT, operations, human resources, communications, management, and other functions appropriate to the organization.\n\nSource fact: The FTC advises moving quickly to stop additional loss, determine the source and scope, identify affected information and people, preserve evidence, correct vulnerabilities, document the investigation, and communicate accurately. It warns organizations not to turn affected machines off before forensic experts advise because powering down can affect evidence.\n\nSource fact: Notification duties vary. The FTC notes state and federal requirements and additional rules that may apply based on the information and organization. It advises consultation with counsel and coordination with law enforcement where appropriate.\n\n## Coordinate overlapping response workstreams\n\nDSE recommendation: use the organization’s approved plan and activate qualified internal and external resources. Engage counsel and any insurer promptly when required by law, policy, or contract while qualified responders preserve evidence and contain harm. There is no universal sequence: legal, forensic, operational, safety, law-enforcement, insurer, vendor, and notification work can overlap, and their order depends on the facts and applicable obligations.\n\n- Protect people and essential operations, stop additional data loss, and preserve volatile and forensic evidence under qualified direction.\n\n- Determine the entry path, duration, systems, identities, persistence, data types, affected individuals or organizations, and remaining exposure.\n\n- Secure physical and digital access, compromised credentials, exposed information, affected integrations, and vulnerable systems without assuming the first containment action removed the actor.\n\n- Implement and validate corrective actions, clean restoration, monitoring, and the intended business transaction.\n\n- Document known facts, uncertainty, evidence, decisions, timestamps, scope, communications, and unresolved risk.\n\n- Have counsel determine required notices and timing; coordinate clear communications and practical affected-person guidance.\n\n## Communicate facts without creating more harm\n\nDSE recommendation: designate an approved spokesperson and maintain one reviewed fact record. Explain what is known, what information was involved, what the organization has done, what affected people can do, and where updates will appear when counsel determines communication is appropriate. Do not speculate, minimize confirmed impact, disclose details that increase risk, or promise a result the investigation cannot support.\n\n## Applicability and limits\n\nThe FTC publication is general U.S. business guidance, not legal advice or a complete notification-law matrix. Requirements change and depend on jurisdiction, sector, data, contracts, insurer terms, and facts. This article intentionally provides no universal deadline or fixed response sequence. Organizations outside the United States need guidance for their applicable jurisdictions.\n\n## Official reference\n\n[Data Breach Response: A Guide for Business](https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business) — FTC operational and notification considerations." }, { "id": "https://update.dsesecurity.com/updates/secure-verifiable-technology-procurement/", "slug": "secure-verifiable-technology-procurement", "url": "https://update.dsesecurity.com/updates/secure-verifiable-technology-procurement/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/secure-verifiable-technology-procurement.md", "json": "https://update.dsesecurity.com/api/v1/posts/secure-verifiable-technology-procurement/" }, "title": "Demand evidence, not promises, when buying digital technology", "summary": "Secure technology procurement evaluates verifiable evidence before purchase and throughout the lifecycle, including defaults, development, components, updates, access, data, support, and exit.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 447, "potentially_affected": "Executives, procurement teams, IT and security leaders, risk advisers, product owners, and manufacturers buying or supplying digital products and services.", "dse_recommendation": "Define requirements before solicitation, request proportionate security evidence, distinguish assurance types, validate critical claims, record residual risk, and reassess material change.", "primary_source": { "name": "CISA and international partners: Choosing Secure and Verifiable Technologies", "url": "https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies", "published_on": "2024-12-05", "authority": "Cybersecurity and Infrastructure Security Agency" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

A product demonstration can show that a feature exists. It does not prove how the product was developed, whether safe defaults are enabled, what components it contains, how updates are protected, or whether security will be maintained through the promised lifecycle.

\n\n

What the joint procurement guidance says

\n

Source fact: CISA and international partners encourage buyers to evaluate whether a digital product or service is secure before purchase and whether security will be maintained throughout its specified lifecycle. Security considerations integrated into procurement can support informed, risk-based decisions and reduce avoidable operating and incident costs.

\n

Source fact: The co-sealed guidance addresses transparency and reporting, secure defaults, security requirements, supply-chain risk, open-source use, data sharing and sovereignty, development, manufacturer access, insider risk, open standards, connected systems, delivery integrity, updates, and post-purchase management.

\n

Source fact: Manufacturer evidence can include attestations, independent assessment, testing, development practices, component transparency, vulnerability handling, digital signatures, and update-delivery controls. The publication states that it is not an exhaustive checklist and cannot guarantee a perfect procurement outcome.

\n\n

Define evidence before accepting claims

\n

DSE recommendation: document security, privacy, availability, data-location, integration, logging, support, update, recovery, accessibility, and end-of-life requirements before selecting a product. Scale questions and validation to the product’s business impact, privilege, data, connectivity, replaceability, and concentration risk.

\n
    \n
  1. Ask how secure development is governed and what evidence shows testing, component control, change approval, and vulnerability remediation operate.
    2. \n
  2. Identify security features enabled by default, added cost or licensing, unsafe deviations, administrative access, and customer configuration duties.
    3. \n
  3. Review open-source and third-party component governance, signed delivery and updates, support duration, end-of-life notice, and recovery options.
    4. \n
  4. Determine manufacturer and subprocessor access, data use and location, incident notification, log availability, ownership changes, and exit treatment.
    5. \n
  5. Test the claims that matter most in a bounded evaluation and record exceptions and compensating controls.
    6. \n
\n\n

Distinguish kinds of assurance

\n

DSE recommendation: label a statement accurately as a vendor claim, self-attestation, independent assessment, certification, document review, customer test, or observed production evidence. Each supports a different level and scope of confidence. Record residual risk and obtain acceptance from the correct authority rather than converting unanswered questions into assumed compliance.

\n

After purchase, reassess material changes in product design, components, provider ownership, hosting, data use, vulnerabilities, support, update method, or access. Procurement evidence becomes stale when the product changes.

\n\n

Applicability and limits

\n

The full guidance is led by Australia’s ASD/ACSC and co-sealed by CISA and other national authorities. Jurisdiction, sector, contract, sanctions, export, sovereignty, and assurance requirements differ. An attestation or certification is not proof that a product is vulnerability-free, and lack of a particular certificate does not by itself establish insecurity.

\n\n

Official reference

\n

Choosing Secure and Verifiable Technologies — CISA’s official page for the co-sealed procurement guidance.

\n
", "content_text": "A product demonstration can show that a feature exists. It does not prove how the product was developed, whether safe defaults are enabled, what components it contains, how updates are protected, or whether security will be maintained through the promised lifecycle.\n\n What the joint procurement guidance says\n Source fact: CISA and international partners encourage buyers to evaluate whether a digital product or service is secure before purchase and whether security will be maintained throughout its specified lifecycle. Security considerations integrated into procurement can support informed, risk-based decisions and reduce avoidable operating and incident costs.\n Source fact: The co-sealed guidance addresses transparency and reporting, secure defaults, security requirements, supply-chain risk, open-source use, data sharing and sovereignty, development, manufacturer access, insider risk, open standards, connected systems, delivery integrity, updates, and post-purchase management.\n Source fact: Manufacturer evidence can include attestations, independent assessment, testing, development practices, component transparency, vulnerability handling, digital signatures, and update-delivery controls. The publication states that it is not an exhaustive checklist and cannot guarantee a perfect procurement outcome.\n\n Define evidence before accepting claims\n DSE recommendation: document security, privacy, availability, data-location, integration, logging, support, update, recovery, accessibility, and end-of-life requirements before selecting a product. Scale questions and validation to the product’s business impact, privilege, data, connectivity, replaceability, and concentration risk.\n \n Ask how secure development is governed and what evidence shows testing, component control, change approval, and vulnerability remediation operate.\n Identify security features enabled by default, added cost or licensing, unsafe deviations, administrative access, and customer configuration duties.\n Review open-source and third-party component governance, signed delivery and updates, support duration, end-of-life notice, and recovery options.\n Determine manufacturer and subprocessor access, data use and location, incident notification, log availability, ownership changes, and exit treatment.\n Test the claims that matter most in a bounded evaluation and record exceptions and compensating controls.\n \n\n Distinguish kinds of assurance\n DSE recommendation: label a statement accurately as a vendor claim, self-attestation, independent assessment, certification, document review, customer test, or observed production evidence. Each supports a different level and scope of confidence. Record residual risk and obtain acceptance from the correct authority rather than converting unanswered questions into assumed compliance.\n After purchase, reassess material changes in product design, components, provider ownership, hosting, data use, vulnerabilities, support, update method, or access. Procurement evidence becomes stale when the product changes.\n\n Applicability and limits\n The full guidance is led by Australia’s ASD/ACSC and co-sealed by CISA and other national authorities. Jurisdiction, sector, contract, sanctions, export, sovereignty, and assurance requirements differ. An attestation or certification is not proof that a product is vulnerability-free, and lack of a particular certificate does not by itself establish insecurity.\n\n Official reference\n Choosing Secure and Verifiable Technologies — CISA’s official page for the co-sealed procurement guidance.", "content_markdown": "A product demonstration can show that a feature exists. It does not prove how the product was developed, whether safe defaults are enabled, what components it contains, how updates are protected, or whether security will be maintained through the promised lifecycle.\n\n## What the joint procurement guidance says\n\nSource fact: CISA and international partners encourage buyers to evaluate whether a digital product or service is secure before purchase and whether security will be maintained throughout its specified lifecycle. Security considerations integrated into procurement can support informed, risk-based decisions and reduce avoidable operating and incident costs.\n\nSource fact: The co-sealed guidance addresses transparency and reporting, secure defaults, security requirements, supply-chain risk, open-source use, data sharing and sovereignty, development, manufacturer access, insider risk, open standards, connected systems, delivery integrity, updates, and post-purchase management.\n\nSource fact: Manufacturer evidence can include attestations, independent assessment, testing, development practices, component transparency, vulnerability handling, digital signatures, and update-delivery controls. The publication states that it is not an exhaustive checklist and cannot guarantee a perfect procurement outcome.\n\n## Define evidence before accepting claims\n\nDSE recommendation: document security, privacy, availability, data-location, integration, logging, support, update, recovery, accessibility, and end-of-life requirements before selecting a product. Scale questions and validation to the product’s business impact, privilege, data, connectivity, replaceability, and concentration risk.\n\n- Ask how secure development is governed and what evidence shows testing, component control, change approval, and vulnerability remediation operate.\n\n- Identify security features enabled by default, added cost or licensing, unsafe deviations, administrative access, and customer configuration duties.\n\n- Review open-source and third-party component governance, signed delivery and updates, support duration, end-of-life notice, and recovery options.\n\n- Determine manufacturer and subprocessor access, data use and location, incident notification, log availability, ownership changes, and exit treatment.\n\n- Test the claims that matter most in a bounded evaluation and record exceptions and compensating controls.\n\n## Distinguish kinds of assurance\n\nDSE recommendation: label a statement accurately as a vendor claim, self-attestation, independent assessment, certification, document review, customer test, or observed production evidence. Each supports a different level and scope of confidence. Record residual risk and obtain acceptance from the correct authority rather than converting unanswered questions into assumed compliance.\n\nAfter purchase, reassess material changes in product design, components, provider ownership, hosting, data use, vulnerabilities, support, update method, or access. Procurement evidence becomes stale when the product changes.\n\n## Applicability and limits\n\nThe full guidance is led by Australia’s ASD/ACSC and co-sealed by CISA and other national authorities. Jurisdiction, sector, contract, sanctions, export, sovereignty, and assurance requirements differ. An attestation or certification is not proof that a product is vulnerability-free, and lack of a particular certificate does not by itself establish insecurity.\n\n## Official reference\n\n[Choosing Secure and Verifiable Technologies](https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies) — CISA’s official page for the co-sealed procurement guidance." }, { "id": "https://update.dsesecurity.com/updates/incident-response-across-csf-2-functions/", "slug": "incident-response-across-csf-2-functions", "url": "https://update.dsesecurity.com/updates/incident-response-across-csf-2-functions/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/incident-response-across-csf-2-functions.md", "json": "https://update.dsesecurity.com/api/v1/posts/incident-response-across-csf-2-functions/" }, "title": "Make incident response part of every NIST CSF 2.0 function", "summary": "NIST SP 800-61 Rev. 3 integrates incident response across Govern, Identify, Protect, Detect, Respond, and Recover instead of isolating it as an emergency-only process.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 397, "potentially_affected": "Executives, incident leaders, IT and security teams, service owners, communications staff, continuity planners, counsel, and external providers with incident responsibilities.", "dse_recommendation": "Map incident readiness and improvement work to all six CSF functions, exercise the resulting handoffs, and feed evidence from incidents back into governance and safeguards.", "primary_source": { "name": "NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management", "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final", "published_on": "2025-04-03", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

Incident response does not begin when an alert fires. Governance, asset knowledge, safeguards, detection design, recovery preparation, and continuous improvement determine whether a team can make sound decisions when facts are incomplete and time matters.

\n\n

The current NIST model

\n

Source fact: NIST SP 800-61 Rev. 3 supersedes Revision 2 and expresses incident-response recommendations as a NIST Cybersecurity Framework 2.0 Community Profile. NIST places incident response across all six CSF functions: Govern, Identify, Protect, Detect, Respond, and Recover.

\n

Source fact: NIST explains that integrating incident response into cybersecurity risk management can help organizations prepare, reduce the number and impact of incidents, and improve the efficiency and effectiveness of detection, response, and recovery. The publication supplies recommended outcomes and considerations; it is not a product-specific forensic runbook.

\n\n

Translate six functions into operating responsibilities

\n

DSE recommendation: build the response capability as a chain of evidence-backed responsibilities rather than a document owned only by IT.

\n \n\n

Exercise the handoffs

\n

DSE recommendation: choose one credible scenario and walk it from detection through recovery. Record who can declare an incident, isolate a system, engage counsel or insurance, notify providers, approve public communication, accept temporary risk, and authorize restoration. Test alternate contacts and out-of-band communications instead of assuming the normal identity, email, phone, or ticketing service will remain available.

\n

After the exercise, assign each finding to a CSF function, an owner, a due date, and evidence of completion. Improvements may belong in governance, inventory, architecture, contracts, logging, training, recovery, or communications—not only in the response plan.

\n\n

Applicability and limits

\n

SP 800-61 Rev. 3 is risk-management guidance, not legal advice, a breach-notification schedule, or a substitute for sector-specific procedures. Forensic preservation, insurer notice, law-enforcement coordination, employment issues, privacy, and regulatory reporting require qualified review under the actual facts. Use NIST’s current online incident-response resources alongside the publication.

\n\n

Official reference

\n

NIST SP 800-61 Rev. 3 — current incident-response recommendations aligned to CSF 2.0.

\n
", "content_text": "Incident response does not begin when an alert fires. Governance, asset knowledge, safeguards, detection design, recovery preparation, and continuous improvement determine whether a team can make sound decisions when facts are incomplete and time matters.\n\n The current NIST model\n Source fact: NIST SP 800-61 Rev. 3 supersedes Revision 2 and expresses incident-response recommendations as a NIST Cybersecurity Framework 2.0 Community Profile. NIST places incident response across all six CSF functions: Govern, Identify, Protect, Detect, Respond, and Recover.\n Source fact: NIST explains that integrating incident response into cybersecurity risk management can help organizations prepare, reduce the number and impact of incidents, and improve the efficiency and effectiveness of detection, response, and recovery. The publication supplies recommended outcomes and considerations; it is not a product-specific forensic runbook.\n\n Translate six functions into operating responsibilities\n DSE recommendation: build the response capability as a chain of evidence-backed responsibilities rather than a document owned only by IT.\n \n Govern: define authority, risk decisions, policy, roles, external obligations, communications approval, evidence handling, and provider responsibilities.\n Identify: know essential services, assets, data, identities, suppliers, dependencies, and the consequences of loss or manipulation.\n Protect: operate safeguards that reduce likelihood or impact and preserve trusted administrative and recovery paths.\n Detect: collect useful telemetry, establish analysis and escalation criteria, and validate that alerts reach accountable responders.\n Respond: analyze, contain, eradicate, coordinate, communicate, preserve evidence, and make documented risk decisions.\n Recover: restore prioritized services, validate integrity and function, communicate status, and manage reconstitution.\n \n\n Exercise the handoffs\n DSE recommendation: choose one credible scenario and walk it from detection through recovery. Record who can declare an incident, isolate a system, engage counsel or insurance, notify providers, approve public communication, accept temporary risk, and authorize restoration. Test alternate contacts and out-of-band communications instead of assuming the normal identity, email, phone, or ticketing service will remain available.\n After the exercise, assign each finding to a CSF function, an owner, a due date, and evidence of completion. Improvements may belong in governance, inventory, architecture, contracts, logging, training, recovery, or communications—not only in the response plan.\n\n Applicability and limits\n SP 800-61 Rev. 3 is risk-management guidance, not legal advice, a breach-notification schedule, or a substitute for sector-specific procedures. Forensic preservation, insurer notice, law-enforcement coordination, employment issues, privacy, and regulatory reporting require qualified review under the actual facts. Use NIST’s current online incident-response resources alongside the publication.\n\n Official reference\n NIST SP 800-61 Rev. 3 — current incident-response recommendations aligned to CSF 2.0.", "content_markdown": "Incident response does not begin when an alert fires. Governance, asset knowledge, safeguards, detection design, recovery preparation, and continuous improvement determine whether a team can make sound decisions when facts are incomplete and time matters.\n\n## The current NIST model\n\nSource fact: NIST SP 800-61 Rev. 3 supersedes Revision 2 and expresses incident-response recommendations as a NIST Cybersecurity Framework 2.0 Community Profile. NIST places incident response across all six CSF functions: Govern, Identify, Protect, Detect, Respond, and Recover.\n\nSource fact: NIST explains that integrating incident response into cybersecurity risk management can help organizations prepare, reduce the number and impact of incidents, and improve the efficiency and effectiveness of detection, response, and recovery. The publication supplies recommended outcomes and considerations; it is not a product-specific forensic runbook.\n\n## Translate six functions into operating responsibilities\n\nDSE recommendation: build the response capability as a chain of evidence-backed responsibilities rather than a document owned only by IT.\n\n- Govern: define authority, risk decisions, policy, roles, external obligations, communications approval, evidence handling, and provider responsibilities.\n\n- Identify: know essential services, assets, data, identities, suppliers, dependencies, and the consequences of loss or manipulation.\n\n- Protect: operate safeguards that reduce likelihood or impact and preserve trusted administrative and recovery paths.\n\n- Detect: collect useful telemetry, establish analysis and escalation criteria, and validate that alerts reach accountable responders.\n\n- Respond: analyze, contain, eradicate, coordinate, communicate, preserve evidence, and make documented risk decisions.\n\n- Recover: restore prioritized services, validate integrity and function, communicate status, and manage reconstitution.\n\n## Exercise the handoffs\n\nDSE recommendation: choose one credible scenario and walk it from detection through recovery. Record who can declare an incident, isolate a system, engage counsel or insurance, notify providers, approve public communication, accept temporary risk, and authorize restoration. Test alternate contacts and out-of-band communications instead of assuming the normal identity, email, phone, or ticketing service will remain available.\n\nAfter the exercise, assign each finding to a CSF function, an owner, a due date, and evidence of completion. Improvements may belong in governance, inventory, architecture, contracts, logging, training, recovery, or communications—not only in the response plan.\n\n## Applicability and limits\n\nSP 800-61 Rev. 3 is risk-management guidance, not legal advice, a breach-notification schedule, or a substitute for sector-specific procedures. Forensic preservation, insurer notice, law-enforcement coordination, employment issues, privacy, and regulatory reporting require qualified review under the actual facts. Use NIST’s current online incident-response resources alongside the publication.\n\n## Official reference\n\n[NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) — current incident-response recommendations aligned to CSF 2.0." }, { "id": "https://update.dsesecurity.com/updates/cybersecurity-event-recovery-playbooks/", "slug": "cybersecurity-event-recovery-playbooks", "url": "https://update.dsesecurity.com/updates/cybersecurity-event-recovery-playbooks/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/cybersecurity-event-recovery-playbooks.md", "json": "https://update.dsesecurity.com/api/v1/posts/cybersecurity-event-recovery-playbooks/" }, "title": "Design cyber recovery playbooks around prioritized services and tested evidence", "summary": "Cyber recovery requires prioritized resources, service-specific playbooks, realistic testing, measurable outcomes, and continuous improvement—not merely a successful backup job.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 387, "potentially_affected": "Organizations whose essential services depend on information systems, cloud services, identities, data, providers, facilities, communications, or specialized personnel.", "dse_recommendation": "Prioritize services and dependencies, document recovery playbooks and validation criteria, run realistic exercises, and improve them using measured results and lessons learned.", "primary_source": { "name": "NIST SP 800-184: Guide for Cybersecurity Event Recovery", "url": "https://csrc.nist.gov/pubs/sp/800/184/final", "published_on": "2016-12-22", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

A backup can be intact while the organization remains unable to operate. Cyber recovery must restore a trustworthy business service, including the identities, data, systems, networks, providers, people, and decisions that service requires.

\n\n

What NIST says recovery planning needs

\n

Source fact: NIST SP 800-184 recommends incorporating cybersecurity-event recovery into organizational risk management. NIST explains that identifying and prioritizing organizational resources supports effective plans and realistic test scenarios, helping an organization recover more rapidly and reduce impact.

\n

Source fact: The publication covers strategic and tactical recovery planning, playbook development, testing, improvement, and example metrics. It also recommends learning from the organization’s own events and relevant events experienced by others. Recovery is therefore a maintained capability, not a one-time document.

\n\n

Start with a service and its dependencies

\n

DSE recommendation: choose an essential service and identify what must be available and trustworthy for it to operate. Include business owners, operators, identity and administrative paths, applications, infrastructure, data, encryption keys, monitoring, network services, facilities, suppliers, communications, and manual alternatives.

\n

Then create a bounded recovery playbook:

\n
    \n
  1. State the activation conditions, decision authority, recovery objective, dependencies, assumptions, and known unsafe actions.
    2. \n
  2. Define containment and evidence-preservation prerequisites before rebuilding or reconnecting technology.
    3. \n
  3. Record the recovery sequence, responsible roles, trusted sources, credentials, clean tools, provider contacts, and alternate communication method.
    4. \n
  4. Specify validation for data integrity, identity, security configuration, monitoring, business transactions, and downstream integrations.
    5. \n
  5. Define who accepts residual risk and authorizes return to production.
    6. \n
\n\n

Test more than restoration speed

\n

DSE recommendation: exercise partial and widespread scenarios, including unavailable identity, unreachable staff, damaged configuration, a compromised administrator, or a supplier outage. Record decision delays, unavailable prerequisites, data outcomes, failed dependencies, validation defects, actual recovery time, and the point at which the service owner accepted operation.

\n

A test that restores files but does not prove the essential transaction, monitoring, access controls, and integrity is incomplete. Retest corrective work rather than closing a finding because a document was updated.

\n\n

Applicability and limits

\n

SP 800-184 was published in 2016. Its planning principles remain useful, but technology examples and implementation details must be reconciled with current vendor documentation, cloud responsibilities, architecture, and obligations. The source does not assign a universal recovery time or guarantee that a playbook will work. Business owners must approve priorities and acceptable operating conditions.

\n\n

Official reference

\n

NIST SP 800-184 — strategic and tactical guidance for cybersecurity-event recovery.

\n
", "content_text": "A backup can be intact while the organization remains unable to operate. Cyber recovery must restore a trustworthy business service, including the identities, data, systems, networks, providers, people, and decisions that service requires.\n\n What NIST says recovery planning needs\n Source fact: NIST SP 800-184 recommends incorporating cybersecurity-event recovery into organizational risk management. NIST explains that identifying and prioritizing organizational resources supports effective plans and realistic test scenarios, helping an organization recover more rapidly and reduce impact.\n Source fact: The publication covers strategic and tactical recovery planning, playbook development, testing, improvement, and example metrics. It also recommends learning from the organization’s own events and relevant events experienced by others. Recovery is therefore a maintained capability, not a one-time document.\n\n Start with a service and its dependencies\n DSE recommendation: choose an essential service and identify what must be available and trustworthy for it to operate. Include business owners, operators, identity and administrative paths, applications, infrastructure, data, encryption keys, monitoring, network services, facilities, suppliers, communications, and manual alternatives.\n Then create a bounded recovery playbook:\n \n State the activation conditions, decision authority, recovery objective, dependencies, assumptions, and known unsafe actions.\n Define containment and evidence-preservation prerequisites before rebuilding or reconnecting technology.\n Record the recovery sequence, responsible roles, trusted sources, credentials, clean tools, provider contacts, and alternate communication method.\n Specify validation for data integrity, identity, security configuration, monitoring, business transactions, and downstream integrations.\n Define who accepts residual risk and authorizes return to production.\n \n\n Test more than restoration speed\n DSE recommendation: exercise partial and widespread scenarios, including unavailable identity, unreachable staff, damaged configuration, a compromised administrator, or a supplier outage. Record decision delays, unavailable prerequisites, data outcomes, failed dependencies, validation defects, actual recovery time, and the point at which the service owner accepted operation.\n A test that restores files but does not prove the essential transaction, monitoring, access controls, and integrity is incomplete. Retest corrective work rather than closing a finding because a document was updated.\n\n Applicability and limits\n SP 800-184 was published in 2016. Its planning principles remain useful, but technology examples and implementation details must be reconciled with current vendor documentation, cloud responsibilities, architecture, and obligations. The source does not assign a universal recovery time or guarantee that a playbook will work. Business owners must approve priorities and acceptable operating conditions.\n\n Official reference\n NIST SP 800-184 — strategic and tactical guidance for cybersecurity-event recovery.", "content_markdown": "A backup can be intact while the organization remains unable to operate. Cyber recovery must restore a trustworthy business service, including the identities, data, systems, networks, providers, people, and decisions that service requires.\n\n## What NIST says recovery planning needs\n\nSource fact: NIST SP 800-184 recommends incorporating cybersecurity-event recovery into organizational risk management. NIST explains that identifying and prioritizing organizational resources supports effective plans and realistic test scenarios, helping an organization recover more rapidly and reduce impact.\n\nSource fact: The publication covers strategic and tactical recovery planning, playbook development, testing, improvement, and example metrics. It also recommends learning from the organization’s own events and relevant events experienced by others. Recovery is therefore a maintained capability, not a one-time document.\n\n## Start with a service and its dependencies\n\nDSE recommendation: choose an essential service and identify what must be available and trustworthy for it to operate. Include business owners, operators, identity and administrative paths, applications, infrastructure, data, encryption keys, monitoring, network services, facilities, suppliers, communications, and manual alternatives.\n\nThen create a bounded recovery playbook:\n\n- State the activation conditions, decision authority, recovery objective, dependencies, assumptions, and known unsafe actions.\n\n- Define containment and evidence-preservation prerequisites before rebuilding or reconnecting technology.\n\n- Record the recovery sequence, responsible roles, trusted sources, credentials, clean tools, provider contacts, and alternate communication method.\n\n- Specify validation for data integrity, identity, security configuration, monitoring, business transactions, and downstream integrations.\n\n- Define who accepts residual risk and authorizes return to production.\n\n## Test more than restoration speed\n\nDSE recommendation: exercise partial and widespread scenarios, including unavailable identity, unreachable staff, damaged configuration, a compromised administrator, or a supplier outage. Record decision delays, unavailable prerequisites, data outcomes, failed dependencies, validation defects, actual recovery time, and the point at which the service owner accepted operation.\n\nA test that restores files but does not prove the essential transaction, monitoring, access controls, and integrity is incomplete. Retest corrective work rather than closing a finding because a document was updated.\n\n## Applicability and limits\n\nSP 800-184 was published in 2016. Its planning principles remain useful, but technology examples and implementation details must be reconciled with current vendor documentation, cloud responsibilities, architecture, and obligations. The source does not assign a universal recovery time or guarantee that a playbook will work. Business owners must approve priorities and acceptable operating conditions.\n\n## Official reference\n\n[NIST SP 800-184](https://csrc.nist.gov/pubs/sp/800/184/final) — strategic and tactical guidance for cybersecurity-event recovery." }, { "id": "https://update.dsesecurity.com/updates/information-system-contingency-planning-bia/", "slug": "information-system-contingency-planning-bia", "url": "https://update.dsesecurity.com/updates/information-system-contingency-planning-bia/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/information-system-contingency-planning-bia.md", "json": "https://update.dsesecurity.com/api/v1/posts/information-system-contingency-planning-bia/" }, "title": "Turn a business impact analysis into an information-system contingency plan", "summary": "A useful contingency plan connects business processes to system components, prioritizes recovery needs, selects practical strategies, and proves the procedures through training and exercises.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 392, "potentially_affected": "Service owners, continuity planners, IT leaders, system administrators, risk managers, and suppliers responsible for information systems that support essential business processes.", "dse_recommendation": "Perform a business impact analysis, select recovery strategies, document activation through reconstitution, exercise the plan, and maintain it as systems and dependencies change.", "primary_source": { "name": "NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems", "url": "https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final", "published_on": "2010-11-11", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

A contingency plan should explain how an information system will support prioritized business needs through disruption and restoration. Copying a generic recovery template cannot establish those priorities or reveal the people, data, facilities, providers, and technical dependencies unique to the service.

\n\n

The NIST planning method

\n

Source fact: NIST SP 800-34 Rev. 1 provides guidance on the purpose, process, and format of information-system contingency planning. It relates contingency plans to incident response, disaster recovery, emergency management, organizational resilience, and the system development life cycle.

\n

Source fact: NIST describes a planning process that includes policy, a business impact analysis, preventive controls, recovery strategies, plan development, testing/training/exercises, and plan maintenance. The business impact analysis connects business processes to supporting system components and helps determine priorities and contingency requirements.

\n\n

Build from business impact

\n

DSE recommendation: begin with business owners and document the service delivered, the effect of interruption or incorrect data over time, dependencies, seasonal constraints, manual alternatives, and the conditions required for safe operation. Avoid assigning recovery targets because another organization uses them.

\n
    \n
  1. Identify business processes and the system components, identities, data, networks, facilities, staff, and suppliers that support them.
    2. \n
  2. Prioritize those components using the documented business impact and dependency order.
    3. \n
  3. Evaluate preventive controls that can reduce disruption or improve availability.
    4. \n
  4. Select recovery strategies that are feasible within resource, architecture, safety, contractual, and support constraints.
    5. \n
  5. Document activation, notification, assessment, recovery, validation, reconstitution, and return-to-normal procedures.
    6. \n
  6. Assign plan ownership, training, exercise frequency, evidence, finding management, and change triggers.
    7. \n
\n\n

Exercise decisions and dependencies

\n

DSE recommendation: test whether the team can reach the plan, obtain credentials, contact providers, recover required configuration and data, communicate without normal channels, and validate the business process. A tabletop can test authority and coordination; a technical recovery test can prove procedures and dependencies. Neither automatically proves the other.

\n

Update the plan after architecture, application, identity, provider, facility, staffing, data, or business-process changes. Track unresolved exercise findings as operating risk with accountable owners.

\n\n

Applicability and limits

\n

This 2010 publication was written for U.S. federal information systems. Nonfederal organizations can adapt the method, but should not present it as a private-sector mandate. Cloud and SaaS services, modern identity dependencies, current cyber threats, and present legal or contractual requirements need separate current analysis. Vendor recovery documentation and shared-responsibility terms still apply.

\n\n

Official reference

\n

NIST SP 800-34 Rev. 1 — information-system contingency planning and business impact analysis guidance.

\n
", "content_text": "A contingency plan should explain how an information system will support prioritized business needs through disruption and restoration. Copying a generic recovery template cannot establish those priorities or reveal the people, data, facilities, providers, and technical dependencies unique to the service.\n\n The NIST planning method\n Source fact: NIST SP 800-34 Rev. 1 provides guidance on the purpose, process, and format of information-system contingency planning. It relates contingency plans to incident response, disaster recovery, emergency management, organizational resilience, and the system development life cycle.\n Source fact: NIST describes a planning process that includes policy, a business impact analysis, preventive controls, recovery strategies, plan development, testing/training/exercises, and plan maintenance. The business impact analysis connects business processes to supporting system components and helps determine priorities and contingency requirements.\n\n Build from business impact\n DSE recommendation: begin with business owners and document the service delivered, the effect of interruption or incorrect data over time, dependencies, seasonal constraints, manual alternatives, and the conditions required for safe operation. Avoid assigning recovery targets because another organization uses them.\n \n Identify business processes and the system components, identities, data, networks, facilities, staff, and suppliers that support them.\n Prioritize those components using the documented business impact and dependency order.\n Evaluate preventive controls that can reduce disruption or improve availability.\n Select recovery strategies that are feasible within resource, architecture, safety, contractual, and support constraints.\n Document activation, notification, assessment, recovery, validation, reconstitution, and return-to-normal procedures.\n Assign plan ownership, training, exercise frequency, evidence, finding management, and change triggers.\n \n\n Exercise decisions and dependencies\n DSE recommendation: test whether the team can reach the plan, obtain credentials, contact providers, recover required configuration and data, communicate without normal channels, and validate the business process. A tabletop can test authority and coordination; a technical recovery test can prove procedures and dependencies. Neither automatically proves the other.\n Update the plan after architecture, application, identity, provider, facility, staffing, data, or business-process changes. Track unresolved exercise findings as operating risk with accountable owners.\n\n Applicability and limits\n This 2010 publication was written for U.S. federal information systems. Nonfederal organizations can adapt the method, but should not present it as a private-sector mandate. Cloud and SaaS services, modern identity dependencies, current cyber threats, and present legal or contractual requirements need separate current analysis. Vendor recovery documentation and shared-responsibility terms still apply.\n\n Official reference\n NIST SP 800-34 Rev. 1 — information-system contingency planning and business impact analysis guidance.", "content_markdown": "A contingency plan should explain how an information system will support prioritized business needs through disruption and restoration. Copying a generic recovery template cannot establish those priorities or reveal the people, data, facilities, providers, and technical dependencies unique to the service.\n\n## The NIST planning method\n\nSource fact: NIST SP 800-34 Rev. 1 provides guidance on the purpose, process, and format of information-system contingency planning. It relates contingency plans to incident response, disaster recovery, emergency management, organizational resilience, and the system development life cycle.\n\nSource fact: NIST describes a planning process that includes policy, a business impact analysis, preventive controls, recovery strategies, plan development, testing/training/exercises, and plan maintenance. The business impact analysis connects business processes to supporting system components and helps determine priorities and contingency requirements.\n\n## Build from business impact\n\nDSE recommendation: begin with business owners and document the service delivered, the effect of interruption or incorrect data over time, dependencies, seasonal constraints, manual alternatives, and the conditions required for safe operation. Avoid assigning recovery targets because another organization uses them.\n\n- Identify business processes and the system components, identities, data, networks, facilities, staff, and suppliers that support them.\n\n- Prioritize those components using the documented business impact and dependency order.\n\n- Evaluate preventive controls that can reduce disruption or improve availability.\n\n- Select recovery strategies that are feasible within resource, architecture, safety, contractual, and support constraints.\n\n- Document activation, notification, assessment, recovery, validation, reconstitution, and return-to-normal procedures.\n\n- Assign plan ownership, training, exercise frequency, evidence, finding management, and change triggers.\n\n## Exercise decisions and dependencies\n\nDSE recommendation: test whether the team can reach the plan, obtain credentials, contact providers, recover required configuration and data, communicate without normal channels, and validate the business process. A tabletop can test authority and coordination; a technical recovery test can prove procedures and dependencies. Neither automatically proves the other.\n\nUpdate the plan after architecture, application, identity, provider, facility, staffing, data, or business-process changes. Track unresolved exercise findings as operating risk with accountable owners.\n\n## Applicability and limits\n\nThis 2010 publication was written for U.S. federal information systems. Nonfederal organizations can adapt the method, but should not present it as a private-sector mandate. Cloud and SaaS services, modern identity dependencies, current cyber threats, and present legal or contractual requirements need separate current analysis. Vendor recovery documentation and shared-responsibility terms still apply.\n\n## Official reference\n\n[NIST SP 800-34 Rev. 1](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) — information-system contingency planning and business impact analysis guidance." }, { "id": "https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements/", "slug": "fema-essential-functions-continuity-elements", "url": "https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements.md", "json": "https://update.dsesecurity.com/api/v1/posts/fema-essential-functions-continuity-elements/" }, "title": "Keep essential functions running with FEMA continuity elements", "summary": "FEMA continuity guidance connects essential functions to authority, people, facilities, communications, vital records, technology, devolution, reconstitution, and recurring exercises.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 412, "potentially_affected": "Private-sector organizations, critical-infrastructure owners, nongovernmental organizations, and public entities developing or refreshing continuity capabilities.", "dse_recommendation": "Identify essential functions, address each FEMA continuity element, coordinate related plans, exercise degraded conditions, and maintain evidence-backed improvements.", "primary_source": { "name": "FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular", "url": "https://preptoolkit.fema.gov/web/cip-citap/ncig/-/knowledge_base/ncig/e-6-continuity-guidance-circular", "published_on": null, "authority": "Federal Emergency Management Agency" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

Continuity is broader than keeping equipment powered. An organization must preserve essential functions when normal leaders, staff, facilities, communications, records, technology, or suppliers are unavailable—and then return to a stable operating state.

\n\n

What FEMA’s circular covers

\n

Source fact: FEMA’s Continuity Guidance Circular is intended for the whole community, including state, local, tribal, and territorial governments, nongovernmental organizations, and private-sector critical-infrastructure owners and operators. It supplies a framework that organizations can tailor based on applicable requirements, resources, size, functions, and risk.

\n

Source fact: FEMA continuity elements include essential functions, orders of succession, delegations of authority, continuity facilities, continuity communications, vital records, human capital, devolution, reconstitution, and testing, training, and exercises. The circular also calls for coordination with emergency operations, incident management, information-technology disaster recovery, pandemic, and business-continuity planning.

\n\n

A whole-service continuity review

\n

DSE recommendation: select one essential function and review every element against real operating evidence:

\n
    \n
  1. Define the function, its priority, minimum acceptable output, dependencies, and the consequences of interruption.
    2. \n
  2. Name successors and document delegations with activation, scope, limits, and communication requirements.
    3. \n
  3. Identify alternate facilities and remote options, including safety, access, equipment, connectivity, and logistical support.
    4. \n
  4. Maintain redundant communication methods for leadership, staff, partners, suppliers, and customers when normal channels fail.
    5. \n
  5. Identify vital records, where protected copies exist, who can retrieve them, and how their integrity and currency are verified.
    6. \n
  6. Plan critical staffing, cross-training, accessibility, health and safety, and support for extended operations.
    7. \n
  7. Define devolution when normal leadership or operations cannot perform the function and reconstitution when stable operations can resume.
    8. \n
\n\n

Exercise the degraded condition

\n

DSE recommendation: do not exercise only the best case. Remove a facility, communications channel, key decision maker, identity service, or supplier from the scenario. Confirm that people can locate current plans and records, understand authority, communicate, perform the minimum function, and report status. Record findings, owners, due dates, retest criteria, and any accepted residual risk.

\n

Coordinate improvements across continuity, emergency action, cyber incident, disaster recovery, occupational safety, crisis communications, and supplier plans. Contradictory activation authority or contact information can make individually polished plans fail together.

\n\n

Applicability and limits

\n

The circular is national guidance, not a universal private-sector regulation or a replacement for sector, accreditation, contractual, legal, or safety requirements. Organizations decide which options fit their circumstances. The guidance does not establish a guaranteed continuity duration, and having a written element does not prove it works.

\n\n

Official reference

\n

FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular — FEMA’s official overview of continuity capabilities for sustaining essential functions and critical services.

\n
", "content_text": "Continuity is broader than keeping equipment powered. An organization must preserve essential functions when normal leaders, staff, facilities, communications, records, technology, or suppliers are unavailable—and then return to a stable operating state.\n\n What FEMA’s circular covers\n Source fact: FEMA’s Continuity Guidance Circular is intended for the whole community, including state, local, tribal, and territorial governments, nongovernmental organizations, and private-sector critical-infrastructure owners and operators. It supplies a framework that organizations can tailor based on applicable requirements, resources, size, functions, and risk.\n Source fact: FEMA continuity elements include essential functions, orders of succession, delegations of authority, continuity facilities, continuity communications, vital records, human capital, devolution, reconstitution, and testing, training, and exercises. The circular also calls for coordination with emergency operations, incident management, information-technology disaster recovery, pandemic, and business-continuity planning.\n\n A whole-service continuity review\n DSE recommendation: select one essential function and review every element against real operating evidence:\n \n Define the function, its priority, minimum acceptable output, dependencies, and the consequences of interruption.\n Name successors and document delegations with activation, scope, limits, and communication requirements.\n Identify alternate facilities and remote options, including safety, access, equipment, connectivity, and logistical support.\n Maintain redundant communication methods for leadership, staff, partners, suppliers, and customers when normal channels fail.\n Identify vital records, where protected copies exist, who can retrieve them, and how their integrity and currency are verified.\n Plan critical staffing, cross-training, accessibility, health and safety, and support for extended operations.\n Define devolution when normal leadership or operations cannot perform the function and reconstitution when stable operations can resume.\n \n\n Exercise the degraded condition\n DSE recommendation: do not exercise only the best case. Remove a facility, communications channel, key decision maker, identity service, or supplier from the scenario. Confirm that people can locate current plans and records, understand authority, communicate, perform the minimum function, and report status. Record findings, owners, due dates, retest criteria, and any accepted residual risk.\n Coordinate improvements across continuity, emergency action, cyber incident, disaster recovery, occupational safety, crisis communications, and supplier plans. Contradictory activation authority or contact information can make individually polished plans fail together.\n\n Applicability and limits\n The circular is national guidance, not a universal private-sector regulation or a replacement for sector, accreditation, contractual, legal, or safety requirements. Organizations decide which options fit their circumstances. The guidance does not establish a guaranteed continuity duration, and having a written element does not prove it works.\n\n Official reference\n FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular — FEMA’s official overview of continuity capabilities for sustaining essential functions and critical services.", "content_markdown": "Continuity is broader than keeping equipment powered. An organization must preserve essential functions when normal leaders, staff, facilities, communications, records, technology, or suppliers are unavailable—and then return to a stable operating state.\n\n## What FEMA’s circular covers\n\nSource fact: FEMA’s Continuity Guidance Circular is intended for the whole community, including state, local, tribal, and territorial governments, nongovernmental organizations, and private-sector critical-infrastructure owners and operators. It supplies a framework that organizations can tailor based on applicable requirements, resources, size, functions, and risk.\n\nSource fact: FEMA continuity elements include essential functions, orders of succession, delegations of authority, continuity facilities, continuity communications, vital records, human capital, devolution, reconstitution, and testing, training, and exercises. The circular also calls for coordination with emergency operations, incident management, information-technology disaster recovery, pandemic, and business-continuity planning.\n\n## A whole-service continuity review\n\nDSE recommendation: select one essential function and review every element against real operating evidence:\n\n- Define the function, its priority, minimum acceptable output, dependencies, and the consequences of interruption.\n\n- Name successors and document delegations with activation, scope, limits, and communication requirements.\n\n- Identify alternate facilities and remote options, including safety, access, equipment, connectivity, and logistical support.\n\n- Maintain redundant communication methods for leadership, staff, partners, suppliers, and customers when normal channels fail.\n\n- Identify vital records, where protected copies exist, who can retrieve them, and how their integrity and currency are verified.\n\n- Plan critical staffing, cross-training, accessibility, health and safety, and support for extended operations.\n\n- Define devolution when normal leadership or operations cannot perform the function and reconstitution when stable operations can resume.\n\n## Exercise the degraded condition\n\nDSE recommendation: do not exercise only the best case. Remove a facility, communications channel, key decision maker, identity service, or supplier from the scenario. Confirm that people can locate current plans and records, understand authority, communicate, perform the minimum function, and report status. Record findings, owners, due dates, retest criteria, and any accepted residual risk.\n\nCoordinate improvements across continuity, emergency action, cyber incident, disaster recovery, occupational safety, crisis communications, and supplier plans. Contradictory activation authority or contact information can make individually polished plans fail together.\n\n## Applicability and limits\n\nThe circular is national guidance, not a universal private-sector regulation or a replacement for sector, accreditation, contractual, legal, or safety requirements. Organizations decide which options fit their circumstances. The guidance does not establish a guaranteed continuity duration, and having a written element does not prove it works.\n\n## Official reference\n\n[FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular](https://preptoolkit.fema.gov/web/cip-citap/ncig/-/knowledge_base/ncig/e-6-continuity-guidance-circular) — FEMA’s official overview of continuity capabilities for sustaining essential functions and critical services." }, { "id": "https://update.dsesecurity.com/updates/ups-readiness-business-continuity/", "slug": "ups-readiness-business-continuity", "url": "https://update.dsesecurity.com/updates/ups-readiness-business-continuity/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/ups-readiness-business-continuity.md", "json": "https://update.dsesecurity.com/api/v1/posts/ups-readiness-business-continuity/" }, "title": "UPS readiness means more than seeing a green status light", "summary": "A useful UPS program connects supported load, required runtime, battery and environmental condition, monitoring, maintenance, controlled testing, and shutdown or recovery plans.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T19:04:47+00:00", "modified_at": "2026-07-19T19:29:33+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 458, "potentially_affected": "Organizations relying on UPS units for network switches, servers, storage, communications, cameras, access-control infrastructure, or management appliances.", "dse_recommendation": "Document each UPS and supported load, review manufacturer status and maintenance guidance, test alerts and recovery safely, and plan battery and unit replacement.", "primary_source": { "name": "Eaton — Considerations for UPS installation", "url": "https://www.eaton.com/us/en-us/products/backup-power-ups-surge-it-power-distribution/backup-power-ups/consideration-for-ups-installation.html", "published_on": null, "authority": "Eaton" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Availability starts with a defined outcome

\n

A UPS is useful only when its design and condition support the business outcome expected during a power event. That outcome may be continued operation for a defined period, enough time for another power source to take over, or an orderly shutdown. A green indicator at one moment does not establish available runtime, battery condition, alert delivery, or correct shutdown behavior.

\n

Eaton’s installation and maintenance guidance emphasizes planning for load, environment, batteries, service, and records. Exact procedures and limits depend on the model, battery system, installation, and manufacturer instructions.

\n\n

Inventory the complete power path

\n

Record the UPS model, serial number, location, installation date, input and output arrangement, battery modules, network management interface, service owner, and supported equipment. Map downstream power distribution so teams know which switches, servers, storage systems, controllers, recorders, or communications devices will be affected together.

\n

Compare the actual connected load with the unit’s supported design and the runtime required by the continuity plan. Include planned growth and devices powered indirectly through network switches. Do not assume a nameplate estimate represents runtime under current batteries, temperature, configuration, and load.

\n\n

Monitor condition and environment

\n\n

Battery condition is affected by factors including age, storage, temperature, chemistry, and cycling. Use model-specific diagnostics and service recommendations rather than a universal replacement interval.

\n\n

Test without creating the outage you are trying to prevent

\n

Plan tests around the protected service, not just the UPS. Identify stakeholders, acceptable impact, monitoring, a safe abort condition, and recovery steps. Verify alerts and management visibility. Where a controlled runtime or transfer test is appropriate, follow manufacturer instructions and use qualified personnel. Never unplug a production UPS or open energized equipment merely to see what happens.

\n

After testing, confirm representative end-to-end services: network connectivity, recording, access events, applications, storage, time synchronization, and alerting. A device may remain powered while a dependent service fails to recover correctly.

\n\n

Prepare for maintenance and replacement

\n

Define who can service the unit, how loads will be protected during work, where approved replacement components come from, and how batteries will be handled and disposed of under applicable requirements. Preserve current configuration and shutdown documentation. Track end-of-support information and plan replacement before parts or expertise become difficult to obtain.

\n

This checklist is operational guidance, not electrical or life-safety instruction. Installation, bypass work, battery replacement, and internal service must follow the manufacturer’s documentation and be performed by appropriately qualified personnel.

", "content_text": "Availability starts with a defined outcome\nA UPS is useful only when its design and condition support the business outcome expected during a power event. That outcome may be continued operation for a defined period, enough time for another power source to take over, or an orderly shutdown. A green indicator at one moment does not establish available runtime, battery condition, alert delivery, or correct shutdown behavior.\nEaton’s installation and maintenance guidance emphasizes planning for load, environment, batteries, service, and records. Exact procedures and limits depend on the model, battery system, installation, and manufacturer instructions.\n\nInventory the complete power path\nRecord the UPS model, serial number, location, installation date, input and output arrangement, battery modules, network management interface, service owner, and supported equipment. Map downstream power distribution so teams know which switches, servers, storage systems, controllers, recorders, or communications devices will be affected together.\nCompare the actual connected load with the unit’s supported design and the runtime required by the continuity plan. Include planned growth and devices powered indirectly through network switches. Do not assume a nameplate estimate represents runtime under current batteries, temperature, configuration, and load.\n\nMonitor condition and environment\n\nReview device alarms, battery status, load, temperature, event history, and self-test results.\nConfirm time, network settings, notification recipients, and the health of the alert path.\nKeep ventilation and service clearances consistent with manufacturer instructions.\nRecord battery and component service instead of relying on memory or labels alone.\nInvestigate recurring transfers, overloads, temperature alarms, and communication failures.\n\nBattery condition is affected by factors including age, storage, temperature, chemistry, and cycling. Use model-specific diagnostics and service recommendations rather than a universal replacement interval.\n\nTest without creating the outage you are trying to prevent\nPlan tests around the protected service, not just the UPS. Identify stakeholders, acceptable impact, monitoring, a safe abort condition, and recovery steps. Verify alerts and management visibility. Where a controlled runtime or transfer test is appropriate, follow manufacturer instructions and use qualified personnel. Never unplug a production UPS or open energized equipment merely to see what happens.\nAfter testing, confirm representative end-to-end services: network connectivity, recording, access events, applications, storage, time synchronization, and alerting. A device may remain powered while a dependent service fails to recover correctly.\n\nPrepare for maintenance and replacement\nDefine who can service the unit, how loads will be protected during work, where approved replacement components come from, and how batteries will be handled and disposed of under applicable requirements. Preserve current configuration and shutdown documentation. Track end-of-support information and plan replacement before parts or expertise become difficult to obtain.\nThis checklist is operational guidance, not electrical or life-safety instruction. Installation, bypass work, battery replacement, and internal service must follow the manufacturer’s documentation and be performed by appropriately qualified personnel.", "content_markdown": "## Availability starts with a defined outcome\n\nA UPS is useful only when its design and condition support the business outcome expected during a power event. That outcome may be continued operation for a defined period, enough time for another power source to take over, or an orderly shutdown. A green indicator at one moment does not establish available runtime, battery condition, alert delivery, or correct shutdown behavior.\n\nEaton’s installation and maintenance guidance emphasizes planning for load, environment, batteries, service, and records. Exact procedures and limits depend on the model, battery system, installation, and manufacturer instructions.\n\n## Inventory the complete power path\n\nRecord the UPS model, serial number, location, installation date, input and output arrangement, battery modules, network management interface, service owner, and supported equipment. Map downstream power distribution so teams know which switches, servers, storage systems, controllers, recorders, or communications devices will be affected together.\n\nCompare the actual connected load with the unit’s supported design and the runtime required by the continuity plan. Include planned growth and devices powered indirectly through network switches. Do not assume a nameplate estimate represents runtime under current batteries, temperature, configuration, and load.\n\n## Monitor condition and environment\n\n- Review device alarms, battery status, load, temperature, event history, and self-test results.\n\n- Confirm time, network settings, notification recipients, and the health of the alert path.\n\n- Keep ventilation and service clearances consistent with manufacturer instructions.\n\n- Record battery and component service instead of relying on memory or labels alone.\n\n- Investigate recurring transfers, overloads, temperature alarms, and communication failures.\n\nBattery condition is affected by factors including age, storage, temperature, chemistry, and cycling. Use model-specific diagnostics and service recommendations rather than a universal replacement interval.\n\n## Test without creating the outage you are trying to prevent\n\nPlan tests around the protected service, not just the UPS. Identify stakeholders, acceptable impact, monitoring, a safe abort condition, and recovery steps. Verify alerts and management visibility. Where a controlled runtime or transfer test is appropriate, follow manufacturer instructions and use qualified personnel. Never unplug a production UPS or open energized equipment merely to see what happens.\n\nAfter testing, confirm representative end-to-end services: network connectivity, recording, access events, applications, storage, time synchronization, and alerting. A device may remain powered while a dependent service fails to recover correctly.\n\n## Prepare for maintenance and replacement\n\nDefine who can service the unit, how loads will be protected during work, where approved replacement components come from, and how batteries will be handled and disposed of under applicable requirements. Preserve current configuration and shutdown documentation. Track end-of-support information and plan replacement before parts or expertise become difficult to obtain.\n\nThis checklist is operational guidance, not electrical or life-safety instruction. Installation, bypass work, battery replacement, and internal service must follow the manufacturer’s documentation and be performed by appropriately qualified personnel." }, { "id": "https://update.dsesecurity.com/updates/microsoft-365-offboarding-secure-preserve-sequence/", "slug": "microsoft-365-offboarding-secure-preserve-sequence", "url": "https://update.dsesecurity.com/updates/microsoft-365-offboarding-secure-preserve-sequence/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-365-offboarding-secure-preserve-sequence.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-365-offboarding-secure-preserve-sequence/" }, "title": "Microsoft 365 offboarding: secure access and preserve business records in the right order", "summary": "Offboarding is an identity, device, records, and continuity workflow. Blocking sign-in is urgent, while mailbox, OneDrive, ownership, legal hold, forwarding, licensing, and account deletion decisions must follow an approved sequence.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T19:04:22+00:00", "modified_at": "2026-07-19T19:04:22+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 469, "potentially_affected": "Microsoft 365 users who leave an organization or change roles, including cloud-only and directory-synchronized identities, managed devices, mailboxes, OneDrive data, Teams, groups, applications, and administrative access.", "dse_recommendation": "Use a time-bound HR and IT checklist that blocks access first, preserves required records, transfers ownership, addresses devices and applications, and removes licenses or accounts only after retention decisions are verified.", "primary_source": { "name": "Microsoft Learn: Remove a former employee and secure data", "url": "https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/remove-former-employee?view=o365-worldwide", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Start with an authorized trigger and a precise time

\n

A reliable offboarding process begins with an approved request from the accountable business or HR owner. Record the identity, effective time, manager, employment status, device ownership, special legal instructions, and people responsible for each action. Urgent termination and planned departure can use the same checklist with different timing.

\n

At the effective time, prevent sign-in, reset credentials as appropriate, revoke active sessions, and remove privileged role eligibility or assignments. Review authentication methods, application passwords, registered devices, delegated access, enterprise applications, API credentials, and shared secrets owned by the person. If the identity is synchronized from on-premises Active Directory, make the authoritative lifecycle change in the source directory; Microsoft notes that deletion and restoration cannot be managed only in Microsoft 365 in that model.

\n

Protect devices and preserve evidence

\n

Decide whether each device is company-owned or personal before issuing retire, wipe, or lock actions. A full wipe and a selective organizational-data removal have materially different consequences, and support varies by enrollment platform. Preserve security evidence needed for an investigation before destructive actions.

\n

Records disposition must precede license removal and account deletion. Determine whether legal hold, retention, eDiscovery, regulatory, contractual, or litigation requirements apply. Those capabilities and retention results depend on licensing and configuration. Obtain legal or records-management direction when required; an IT convenience decision is not a substitute.

\n
    \n
  1. Preserve or transfer required mailbox data. Decide whether to convert the mailbox, delegate access, or configure forwarding based on an approved business need.
    2. \n
  2. Grant an accountable successor access to required OneDrive content and transfer ownership of business files, sites, Teams, groups, shared mailboxes, applications, automations, and service documentation.
    3. \n
  3. Remove the user from groups, Teams, distribution lists, shared resources, partner portals, line-of-business systems, VPN, physical access, and vendor services.
    4. \n
  4. Communicate the replacement contact without exposing private employment information.
    5. \n
  5. Remove or reassign licenses only after dependent data and service behavior are confirmed.
    6. \n
  6. Delete the account only when the approved retention and continuity plan permits it.
    7. \n
\n

Treat retention windows as constraints, not backups

\n

Microsoft’s current offboarding guidance describes common 30-day retention and restoration windows for deleted user mailbox and OneDrive content, with different behavior when a license is removed but the account remains. Holds, tenant settings, subscription changes, and future product changes can alter outcomes. Verify the current Microsoft documentation and the tenant’s actual configuration before deletion. A published retention window should not be the only copy of business-critical information.

\n

Close with evidence and a follow-up

\n

Record timestamps, successful session revocation, data custodians, forwarding expiration, license changes, device actions, exceptions, and the final account state. Schedule a follow-up to remove temporary forwarding or delegated access and confirm that no critical workflow depended on the departed identity. Offboarding is complete when access is closed, necessary records are controlled, business ownership is transferred, and temporary measures have an end date.

", "content_text": "Start with an authorized trigger and a precise time\nA reliable offboarding process begins with an approved request from the accountable business or HR owner. Record the identity, effective time, manager, employment status, device ownership, special legal instructions, and people responsible for each action. Urgent termination and planned departure can use the same checklist with different timing.\nAt the effective time, prevent sign-in, reset credentials as appropriate, revoke active sessions, and remove privileged role eligibility or assignments. Review authentication methods, application passwords, registered devices, delegated access, enterprise applications, API credentials, and shared secrets owned by the person. If the identity is synchronized from on-premises Active Directory, make the authoritative lifecycle change in the source directory; Microsoft notes that deletion and restoration cannot be managed only in Microsoft 365 in that model.\nProtect devices and preserve evidence\nDecide whether each device is company-owned or personal before issuing retire, wipe, or lock actions. A full wipe and a selective organizational-data removal have materially different consequences, and support varies by enrollment platform. Preserve security evidence needed for an investigation before destructive actions.\nRecords disposition must precede license removal and account deletion. Determine whether legal hold, retention, eDiscovery, regulatory, contractual, or litigation requirements apply. Those capabilities and retention results depend on licensing and configuration. Obtain legal or records-management direction when required; an IT convenience decision is not a substitute.\n\nPreserve or transfer required mailbox data. Decide whether to convert the mailbox, delegate access, or configure forwarding based on an approved business need.\nGrant an accountable successor access to required OneDrive content and transfer ownership of business files, sites, Teams, groups, shared mailboxes, applications, automations, and service documentation.\nRemove the user from groups, Teams, distribution lists, shared resources, partner portals, line-of-business systems, VPN, physical access, and vendor services.\nCommunicate the replacement contact without exposing private employment information.\nRemove or reassign licenses only after dependent data and service behavior are confirmed.\nDelete the account only when the approved retention and continuity plan permits it.\n\nTreat retention windows as constraints, not backups\nMicrosoft’s current offboarding guidance describes common 30-day retention and restoration windows for deleted user mailbox and OneDrive content, with different behavior when a license is removed but the account remains. Holds, tenant settings, subscription changes, and future product changes can alter outcomes. Verify the current Microsoft documentation and the tenant’s actual configuration before deletion. A published retention window should not be the only copy of business-critical information.\nClose with evidence and a follow-up\nRecord timestamps, successful session revocation, data custodians, forwarding expiration, license changes, device actions, exceptions, and the final account state. Schedule a follow-up to remove temporary forwarding or delegated access and confirm that no critical workflow depended on the departed identity. Offboarding is complete when access is closed, necessary records are controlled, business ownership is transferred, and temporary measures have an end date.", "content_markdown": "## Start with an authorized trigger and a precise time\n\nA reliable offboarding process begins with an approved request from the accountable business or HR owner. Record the identity, effective time, manager, employment status, device ownership, special legal instructions, and people responsible for each action. Urgent termination and planned departure can use the same checklist with different timing.\n\nAt the effective time, prevent sign-in, reset credentials as appropriate, revoke active sessions, and remove privileged role eligibility or assignments. Review authentication methods, application passwords, registered devices, delegated access, enterprise applications, API credentials, and shared secrets owned by the person. If the identity is synchronized from on-premises Active Directory, make the authoritative lifecycle change in the source directory; Microsoft notes that deletion and restoration cannot be managed only in Microsoft 365 in that model.\n\n## Protect devices and preserve evidence\n\nDecide whether each device is company-owned or personal before issuing retire, wipe, or lock actions. A full wipe and a selective organizational-data removal have materially different consequences, and support varies by enrollment platform. Preserve security evidence needed for an investigation before destructive actions.\n\nRecords disposition must precede license removal and account deletion. Determine whether legal hold, retention, eDiscovery, regulatory, contractual, or litigation requirements apply. Those capabilities and retention results depend on licensing and configuration. Obtain legal or records-management direction when required; an IT convenience decision is not a substitute.\n\n- Preserve or transfer required mailbox data. Decide whether to convert the mailbox, delegate access, or configure forwarding based on an approved business need.\n\n- Grant an accountable successor access to required OneDrive content and transfer ownership of business files, sites, Teams, groups, shared mailboxes, applications, automations, and service documentation.\n\n- Remove the user from groups, Teams, distribution lists, shared resources, partner portals, line-of-business systems, VPN, physical access, and vendor services.\n\n- Communicate the replacement contact without exposing private employment information.\n\n- Remove or reassign licenses only after dependent data and service behavior are confirmed.\n\n- Delete the account only when the approved retention and continuity plan permits it.\n\n## Treat retention windows as constraints, not backups\n\nMicrosoft’s current offboarding guidance describes common 30-day retention and restoration windows for deleted user mailbox and OneDrive content, with different behavior when a license is removed but the account remains. Holds, tenant settings, subscription changes, and future product changes can alter outcomes. Verify the current Microsoft documentation and the tenant’s actual configuration before deletion. A published retention window should not be the only copy of business-critical information.\n\n## Close with evidence and a follow-up\n\nRecord timestamps, successful session revocation, data custodians, forwarding expiration, license changes, device actions, exceptions, and the final account state. Schedule a follow-up to remove temporary forwarding or delegated access and confirm that no critical workflow depended on the departed identity. Offboarding is complete when access is closed, necessary records are controlled, business ownership is transferred, and temporary measures have an end date." }, { "id": "https://update.dsesecurity.com/updates/microsoft-365-copilot-permissions-readiness/", "slug": "microsoft-365-copilot-permissions-readiness", "url": "https://update.dsesecurity.com/updates/microsoft-365-copilot-permissions-readiness/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-365-copilot-permissions-readiness.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-365-copilot-permissions-readiness/" }, "title": "Microsoft 365 Copilot permissions readiness: fix oversharing before rollout", "summary": "Microsoft 365 Copilot works within a user's existing permissions. That boundary does not correct excessive access: content already visible to a user may become easier to discover, so SharePoint, OneDrive, Teams, ownership, labels, and sharing need review first.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T19:04:22+00:00", "modified_at": "2026-07-19T19:04:22+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 442, "potentially_affected": "Organizations considering or expanding Microsoft 365 Copilot across users who can access SharePoint, OneDrive, Teams, Exchange, connected applications, and other Microsoft 365 data.", "dse_recommendation": "Inventory permissions and sharing, assign valid content owners, remediate broad access, confirm data-protection licensing and behavior, and pilot Copilot with representative users before wider license assignment.", "primary_source": { "name": "Microsoft Learn: Microsoft 365 Copilot data and compliance readiness", "url": "https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-minimum-requirements-data-compliance", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Permission-aware is not permission-correcting

\n

Microsoft states that Microsoft 365 Copilot operates within a user’s existing permissions and honors Microsoft 365 security, privacy, and compliance controls. It does not grant a user new permission to a file merely because they ask about it. However, existing access can be broader than owners realize. Search, sharing links, group membership, inherited permissions, abandoned sites, and old project spaces can leave users able to reach information they no longer need.

\n

Copilot can make authorized content easier to discover and synthesize. The readiness question is therefore not only whether Copilot respects permissions, but whether the current permissions represent the intended business boundary.

\n

Review the information estate before licenses

\n\n

OneDrive uses SharePoint Online as its underlying platform, so tenant sharing controls also influence personal work files. Microsoft specifically recommends reviewing sharing defaults, site ownership, unused sites, potentially overshared content, and controls for business-critical sites.

\n

Verify protection instead of assuming it

\n

Sensitivity labels, encryption, retention, data-loss prevention, audit, eDiscovery, restricted search, and advanced SharePoint controls have different prerequisites and licenses. A label name alone does not prove that encryption or access restrictions apply. Test the actual user experience with labeled, encrypted, shared, and externally accessible content. Microsoft notes that legacy Information Rights Management content is not used for Copilot grounding and recommends modern sensitivity-labeling approaches where appropriate.

\n

Review meeting, chat, email, plugin, connector, and third-party application scenarios separately. Each connected data source has its own permissions and governance model. Confirm current Microsoft 365 Copilot and workload licenses for every pilot user; possessing a base Microsoft 365 subscription does not automatically mean every Copilot or Purview feature is included.

\n

Pilot for information quality and security

\n

Select representative users from different roles, not only administrators. Use approved test prompts to check whether users can surface sensitive material they should not need, whether important records are missing because of poor organization, and whether citations lead to authoritative content. Teach users to inspect citations, handle generated content according to its sensitivity, and verify important outputs.

\n

Record findings, remediate permission causes, and retest before broad assignment. Continue reviewing guests, sharing links, site owners, stale groups, and Copilot audit data after launch. Copilot readiness is an ongoing information-governance program, not a one-time license deployment.

", "content_text": "Permission-aware is not permission-correcting\nMicrosoft states that Microsoft 365 Copilot operates within a user’s existing permissions and honors Microsoft 365 security, privacy, and compliance controls. It does not grant a user new permission to a file merely because they ask about it. However, existing access can be broader than owners realize. Search, sharing links, group membership, inherited permissions, abandoned sites, and old project spaces can leave users able to reach information they no longer need.\nCopilot can make authorized content easier to discover and synthesize. The readiness question is therefore not only whether Copilot respects permissions, but whether the current permissions represent the intended business boundary.\nReview the information estate before licenses\n\nIdentify SharePoint sites, Teams, Microsoft 365 Groups, and OneDrive locations with broad internal or external access.\nConfirm that every active site has accountable owners and that inactive or ownerless sites have a disposition plan.\nInspect Anyone links, organization-wide links, large groups, nested membership, guest access, and content shared outside its original project.\nPrioritize executive, finance, personnel, legal, security, customer, and merger or acquisition content.\nRemove obsolete access through normal governance and validate that business workflows still function.\n\nOneDrive uses SharePoint Online as its underlying platform, so tenant sharing controls also influence personal work files. Microsoft specifically recommends reviewing sharing defaults, site ownership, unused sites, potentially overshared content, and controls for business-critical sites.\nVerify protection instead of assuming it\nSensitivity labels, encryption, retention, data-loss prevention, audit, eDiscovery, restricted search, and advanced SharePoint controls have different prerequisites and licenses. A label name alone does not prove that encryption or access restrictions apply. Test the actual user experience with labeled, encrypted, shared, and externally accessible content. Microsoft notes that legacy Information Rights Management content is not used for Copilot grounding and recommends modern sensitivity-labeling approaches where appropriate.\nReview meeting, chat, email, plugin, connector, and third-party application scenarios separately. Each connected data source has its own permissions and governance model. Confirm current Microsoft 365 Copilot and workload licenses for every pilot user; possessing a base Microsoft 365 subscription does not automatically mean every Copilot or Purview feature is included.\nPilot for information quality and security\nSelect representative users from different roles, not only administrators. Use approved test prompts to check whether users can surface sensitive material they should not need, whether important records are missing because of poor organization, and whether citations lead to authoritative content. Teach users to inspect citations, handle generated content according to its sensitivity, and verify important outputs.\nRecord findings, remediate permission causes, and retest before broad assignment. Continue reviewing guests, sharing links, site owners, stale groups, and Copilot audit data after launch. Copilot readiness is an ongoing information-governance program, not a one-time license deployment.", "content_markdown": "## Permission-aware is not permission-correcting\n\nMicrosoft states that Microsoft 365 Copilot operates within a user’s existing permissions and honors Microsoft 365 security, privacy, and compliance controls. It does not grant a user new permission to a file merely because they ask about it. However, existing access can be broader than owners realize. Search, sharing links, group membership, inherited permissions, abandoned sites, and old project spaces can leave users able to reach information they no longer need.\n\nCopilot can make authorized content easier to discover and synthesize. The readiness question is therefore not only whether Copilot respects permissions, but whether the current permissions represent the intended business boundary.\n\n## Review the information estate before licenses\n\n- Identify SharePoint sites, Teams, Microsoft 365 Groups, and OneDrive locations with broad internal or external access.\n\n- Confirm that every active site has accountable owners and that inactive or ownerless sites have a disposition plan.\n\n- Inspect Anyone links, organization-wide links, large groups, nested membership, guest access, and content shared outside its original project.\n\n- Prioritize executive, finance, personnel, legal, security, customer, and merger or acquisition content.\n\n- Remove obsolete access through normal governance and validate that business workflows still function.\n\nOneDrive uses SharePoint Online as its underlying platform, so tenant sharing controls also influence personal work files. Microsoft specifically recommends reviewing sharing defaults, site ownership, unused sites, potentially overshared content, and controls for business-critical sites.\n\n## Verify protection instead of assuming it\n\nSensitivity labels, encryption, retention, data-loss prevention, audit, eDiscovery, restricted search, and advanced SharePoint controls have different prerequisites and licenses. A label name alone does not prove that encryption or access restrictions apply. Test the actual user experience with labeled, encrypted, shared, and externally accessible content. Microsoft notes that legacy Information Rights Management content is not used for Copilot grounding and recommends modern sensitivity-labeling approaches where appropriate.\n\nReview meeting, chat, email, plugin, connector, and third-party application scenarios separately. Each connected data source has its own permissions and governance model. Confirm current Microsoft 365 Copilot and workload licenses for every pilot user; possessing a base Microsoft 365 subscription does not automatically mean every Copilot or Purview feature is included.\n\n## Pilot for information quality and security\n\nSelect representative users from different roles, not only administrators. Use approved test prompts to check whether users can surface sensitive material they should not need, whether important records are missing because of poor organization, and whether citations lead to authoritative content. Teach users to inspect citations, handle generated content according to its sensitivity, and verify important outputs.\n\nRecord findings, remediate permission causes, and retest before broad assignment. Continue reviewing guests, sharing links, site owners, stale groups, and Copilot audit data after launch. Copilot readiness is an ongoing information-governance program, not a one-time license deployment." } ] }