> For the complete documentation index, see [llms.txt](https://docs.cipp.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cipp.app/troubleshooting/frequently-asked-questions/standards-v-drift.md). # Standards v Drift: How Do I Know Which to Use? {% hint style="info" %} Baselines combines Standards and Drift into one engine. Turning on the **Baselines** feature flag switches off both, along with their scheduled runs, so the choice on this page only arises while the flag is off. See [Where Baselines Fit](#where-baselines-fit) for how the same decisions carry over. {% endhint %} This question has become a regular one since the introduction of Drift Management. While there is some overlap in how the two can work, they are very different approaches to how you manage the security baseline for your clients' tenants. This is fundamentally a question of how much you want to manage and how much visibility you want to the entire tenant. ### Standards #### What Does Standards Do? Standards are the Ron Popeil Showtime Rotisserie method: "set it and forget it!". Anything that you configure with a standard will be reinforced every twelve hours. You can have multiple templates that can apply to any given tenant and settings priority follow the precedence set out on the main [Standards & Drift](/user-documentation/tenant/standards.md) page. #### What Visibility Does Standards Provide? Compliance reporting for standards is limited to only those standards included in the template. Everything else going on outside of your limited list of standards is left to be reviewed by other methods (alerts, etc.) ### Drift Management #### What Does Drift Management Do? Drift Management is a more managed approach to tenant monitoring. Ideally, you create fewer templates as each tenant can only have one template applied. Drift Management is evaluated every twelve hours. You can optionally select to have certain settings in the template set to automatically remediate if they are found to be out of alignment with the settings in the template. This behaviour is similar to Standards for those settings that you identify must be applied across all tenants assigned to the template. #### What Visibility Does Drift Management Provide? Compliance reporting for Drift Management includes everything whether the setting is included in the template or not. Anything not defined by the template is automatically considered a deviation that must be managed along with settings that don't match the template. ### Which One Should I Use? This is ultimately going to be a decision based on how you want to operate your business and the services you provide to your clients. Drift Management provides you with the greatest visibility into your clients' tenants allowing you to offer drift alignment and deviation review as a part of a more managed security services offering. Standards provides an ease of use with less ongoing review needed but requires more work upfront to clearly define multiple templates for granular control over the various nuances between tenants (licensing, industry, etc.). Standards apply specific settings. Drift monitors the full tenant state. ### Do I Need Both a Classic Template and a Drift Template With the Same Settings? No. A Drift Management template with **auto-remediate enabled** on a setting behaves the same as a Classic standard set to **Remediate** for that setting: it will bring the tenant back into alignment with the template value every twelve hours. With auto-remediate **disabled**, the setting reports as a deviation in [Manage Drift](/user-documentation/tenant/manage/drift.md) for review. The auto-remediate toggle is per-setting inside the drift template, so you can mix-and-match: auto-remediate the non-negotiables (audit log, anonymous reporting), and just report on settings you want eyes on first (Conditional Access changes). You only need a separate Classic template alongside Drift when you want to override a single setting for a specific tenant (see "Mixing All-Tenants, Groups, and Tenant Overrides" below). Remember that each tenant can only be assigned to **one** Drift template. ### Mixing All-Tenants, Groups, and Tenant Overrides A common pattern that works well for MSPs with a mixed-licence customer base: 1. **One Classic standard, assigned to All Tenants**, containing the settings you want enforced everywhere regardless of licence, such as enabling the audit log and anonymous reporting, and setting the helpdesk email as a security contact. 2. **One Drift template per licence tier or customer segment**, assigned via tenant groups. For example: * An *Education* tenant group → Drift template with Entra P1-dependent settings (Conditional Access, App Protection policies). * A *Business Standard* tenant group → Drift template with the Security Defaults standard and other settings appropriate for tenants without Entra P1. Tenant groups can be **static** (you add tenants manually) or **dynamic** (membership based on a licence SKU or a tenant custom variable), letting group membership follow tenant state automatically. See [Tenant Groups](/user-documentation/tenant/administration/tenants/groups.md) for setup. 3. **Tenant-specific Classic templates for one-off variances.** If one client needs `Set SharePoint File Version Limits` set to 200 but your group-level drift template has 100, create a Classic template containing **only** that one standard set to 200 and assign it directly to that tenant. Per the [precedence rules](/user-documentation/tenant/standards.md#precedence-of-standards), the tenant-specific Classic will win for that setting. This pattern keeps your group-level templates clean and your exceptions visible and named, without duplicating the rest of the configuration. {% hint style="info" %} Because licence-incompatible settings are automatically skipped, you *can* lump everything into one big template, but the group-based pattern above gives you cleaner alignment reporting and makes "why is this tenant non-compliant?" easier to answer. {% endhint %} ### Where Baselines Fit [Baselines](/user-documentation/tenant/baselines.md) replace both Standards and Drift Management while the **Baselines** flag is on. Instead of choosing between the two approaches, you make the same choice standard by standard inside one baseline. #### What Does Baselines Do? A baseline is checked against every assigned tenant twice a day. Each standard in it has its own **Automatically fix this when the setting drifts** setting. Turned on, the standard is corrected on every run, like a classic standard set to remediate. Left off, the deviation is only reported, like a Drift setting without auto-remediate. Standards arrive with automatic fixing switched off, so nothing changes in a tenant until you turn it on. Standards are grouped into stages, so a baseline can roll out gradually. Every tenant receives the first stage, and moves into later stages once it meets the graduation conditions you set, for example time spent in the previous stage or approval by an operator. See [Add or Edit Baseline](/user-documentation/tenant/baselines/template.md) for the options. #### What Visibility Does Baselines Provide? Every standard in a baseline is reported on the [Baseline Alignment](/user-documentation/tenant/baselines/alignment.md) page, where each deviation can be accepted, with a reason and an optional expiry date, or denied so it is corrected on the next run. For the whole-tenant view Drift Management gives, add the **Detect Intune Drift** and **Detect Conditional Access Drift** standards to the baseline. They raise a deviation for every Intune or Conditional Access policy in the tenant that no baseline template covers, and never change anything automatically. A policy is only removed once you deny it. #### How Does the Mixed Pattern Translate? The pattern in [Mixing All-Tenants, Groups, and Tenant Overrides](#mixing-all-tenants-groups-and-tenant-overrides) carries over with fewer moving parts: 1. **One baseline assigned to All Tenants**, holding the settings you want enforced everywhere. 2. **One baseline per licence tier or customer segment**, assigned to tenant groups. A tenant can be assigned to more than one baseline, so there is no one-template limit to plan around. 3. **A tenant override for each one-off variance**, created with **Create Tenant Override** on the Baseline Alignment page, instead of a separate tenant-specific template. Where more than one baseline configures the same standard for a tenant, a baseline assigned to the tenant directly beats one assigned through a tenant group, which beats one assigned to All Tenants. A tenant override beats all three. Two baselines at the same level with identical settings for a standard are treated as one. With different settings, the standard shows as **Conflict** and is neither compared nor corrected until you edit one of the baselines. #### How Do I Move Across? **Migrate from Standards** on the [Manage Baselines](/user-documentation/tenant/baselines/templates.md) page converts your classic and drift templates into baselines, leaving the originals untouched. Import everything as report-only, review the results on the Baseline Alignment page, create any tenant overrides you need, then turn on automatic fixing for the standards you want enforced. *** ## Feature Requests / Ideas We value your feedback and ideas. Please raise any [feature requests](https://github.com/CyberDrain/CIPP/issues/new?template=feature.yml) on GitHub. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.cipp.app/troubleshooting/frequently-asked-questions/standards-v-drift.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.