Microsoft Sentinel Azure portal retirement: move to Defender or self-host

Record the retention configuration of every log source before the move and the retention configuration that applies after it, so an assessor can see the change and its date. In Sentinel, the Log Analytics workspace retention and any archive or data lake settings are the baseline. When Sentinel runs in the Microsoft Defender portal, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's, so the new values must be written down and compared against your own retention requirements. In Wazuh, the equivalent evidence is the index lifecycle policy and snapshot schedule in the Wazuh indexer, along with the retention period you set for alerts and archives. Keep exported configuration files and dated screenshots as part of the change record, and confirm each value with the vendor documentation for your tenant.

The OpenSearch Security plugin produces the access control records that show who can read, search and change log data. Export the role definitions, role mappings, internal users list and backend configuration, which cover role-based access control, document-level and field-level security and field masking. Keep the authentication configuration for SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Token backends, because it shows how identities from your directory are tied to those roles. Dated exports taken at each change, together with the approval tickets that authorized them, let an auditor trace each permission back to a decision. Confirm the exact export procedure and file format against the OpenSearch security documentation for your version.

Keep the audit log configuration and the audit logs themselves for the period before, during and after the change. The OpenSearch Security plugin provides audit logging, so record which categories are enabled, where the logs are written and who can read them. Preserve the Sentinel audit history and the Defender portal activity records you export during cutover, since they show who changed analytics rules, connectors and workspace settings. Store the logs in a location that the administrators performing the change cannot alter, and document the retention period you chose for them. Ask your auditor which audit trail they expect for the platform change, because requirements differ by framework and organization.

Keep the TLS configuration for both node-to-node traffic inside the cluster and client traffic from dashboards, agents and ingest sources. For OpenSearch, the Security plugin configuration defines the certificates, certificate authorities and whether client certificates are required. Record the certificate issuer, validity dates, key lengths and the hostnames each certificate covers, and store the configuration files with a hash or version tag. For Wazuh, document the certificates used between agents and the server, between the server and the indexer, and for the dashboard. Include a test result from a TLS scan of each listening port so the configuration is verified, not only described. Confirm the cipher and protocol settings against your own policy before you record them as compliant.

Map each control your assessor cares about to the dashboard view, rule set or report that provides its evidence, and keep the mapping as a dated document. Wazuh's dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, which give a starting point for this mapping. Verify each view against the control wording in your own copy of the standard and state where a view does not cover a control, so the gap is visible. Export the dashboard state and the rule groups used, and keep them with the change record. Refer to the controls by their IDs and titles in the mapping. Use your compliance program or the assessor to confirm which controls apply and what counts as sufficient evidence.

Each rewritten detection rule needs a change record that links the original Sentinel analytics rule, the new rule in the target platform, the reviewer and the test results. Keep the exported ARM template or rule definition from before the move, the new rule file, and a log of the tests that showed the rule fires on the same test data. Note any change in logic, severity, mapped technique or alert routing, because a silent change in detection coverage is the finding auditors are most likely to raise. Store the records in your change management system with approval dates. Ask your assessor how they want rule mappings presented, and confirm the expected format before the cutover.

DeployOpen prepares the systems, controls and evidence for the platform change, including configuration exports, access records, TLS documentation, dashboard mappings and rule change records. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies review the evidence and form any opinion on it. Agree in writing, before work starts, which evidence items are in scope, who receives each one and how it is stored. Ask your assessor to confirm the evidence format and sampling approach in advance, so the work matches what they will test.

Yes, if the evidence is produced on a schedule and assigned to named owners. The recurring items are access exports after each role change, TLS certificate records when certificates renew, retention and audit log reviews, and rule change records for every edit. Each of these is a small, repeatable task, but each needs an owner and a calendar entry. Automate exports where the platform allows it, and store them in a location separate from the systems they describe. Ask your internal audit or compliance lead which review cycle they require, and confirm that cycle with the auditor before the platform goes live.