What Is a Security Baseline

If you’ve been asking, “What security settings are we actually expecting our devices and apps to follow?”, you’re already thinking about what is a security baseline. A baseline is where you write down the minimum (or standard) settings your org approves, so every computer, user, and system component ends up in a predictable, safer state. And if you work with Microsoft technology, you’ll also see Microsoft security baselines—one practical way to turn that general idea into configuration guidance.

Quick note before we go further: Microsoft’s recommendations are just one implementation of the bigger concept. They won’t automatically fit every risk situation, network, or app you run.

What is a security baseline?

A security baseline is a standard set of approved security settings, controls, or configurations that systems are expected to follow. In practice, it’s your org’s “house rules” for security—the minimum rules you want in place.

A baseline usually includes two pieces:

• The settings/controls themselves (what gets enabled, disabled, or configured)
• The security implications (what those choices mean for security risk)

Because it comes from “approved” decisions, a baseline also reflects your org’s risk tolerance and specific requirements. One organization may accept a more flexible baseline for convenience. Another may require stricter settings because of compliance, threat exposure, or the sensitivity of its data.

A useful way to keep three terms straight

Search results often mix closely related phrases. Here are three common ones—security baseline, security control baseline, and Microsoft security baseline—and how they relate:

So: security baseline is the broad idea. security control baseline is a baseline tied to impact and minimum controls. Microsoft security baseline is Microsoft’s recommended configuration baseline you can use as one input when you build your own approach.

Security baseline versus security control baseline

These terms sound similar, but they describe different work.

A security baseline usually defines the configuration target:

• which settings are approved
• what values those settings should have
• how the configuration changes security posture

A security control baseline is usually framed as the minimum security controls an information system needs based on its impact level—low-, moderate-, or high-impact.

A simple mental model:

• Baseline settings answer: “What should we configure?”
• Control baseline answers: “What minimum controls must we have for this system’s impact level?”

In practice, they work together. Controls influence the settings you choose, and the settings you implement show that you applied the controls.

What a security baseline document includes

You won’t always find one universal “template,” but a solid security baseline document typically records both the “what” and the “so what.”

Common elements include:

• Applies to: The system type(s) the baseline covers (for example, an OS version family, an endpoint profile, a user role, or an app category)
• Approved settings/controls: The specific configuration choices (what’s enabled, disabled, or set to a particular value)
• Security implications: How the settings affect security risk
• Ownership and approval: Who approved the baseline and how changes are reviewed
• Operational notes: Dependencies, exceptions, or rollout guidance that helps admins implement it without guesswork

The main point: it’s not just a checklist. It documents a decision about what your org considers an acceptable minimum starting point for security.

How baselines apply to systems, devices, users, and applications

A security baseline can show up in places people don’t always think about. Baselines can apply to:

• Systems: Server or workstation operating environments
• Devices: Physical endpoints and managed device types
• Users: Permissions, authentication behavior, and access patterns
• Applications: Security settings and configurations that the app should follow

Even when the baseline is written as “settings,” the scope can still include users and apps, because those settings affect what access is possible.

Example scenarios (non-Microsoft-specific)

• Computers: Standardize OS and security feature settings for every workstation model.
• Networks: Define approved security controls for network components, including how devices communicate and how access is restricted.
• Users: Require consistent identity security behavior, like how authentication is enforced for particular user groups.
• Applications: Set rules for app-level protections, such as how apps handle authentication or secure communication expectations.

Once you think of baselines as “approved rules” rather than random settings, it’s easier to scale security across the whole org.

Minimum security standards and risk tolerance

In baseline discussions, you’ll often see the phrase minimum security. It means the least amount of approved security settings, controls, or configurations that a system or component should meet.

“Minimum” doesn’t mean “weak.” It means the minimum your org requires to reduce risk to an acceptable level.

That acceptable level varies because risk tolerance depends on things like:

• Data sensitivity
• Business criticality
• Threat exposure
• Compliance obligations
• How much disruption you can tolerate during enforcement

This is also why baselines should be tailored. A secure configuration baseline should align with your organization’s risk tolerance and specific requirements. If you copy a one-size-fits-all set of settings, you may end up with:

• too much security friction, where admins stop using it, or
• not enough protection for the systems that matter most

Microsoft security baselines for Windows and Microsoft 365

Microsoft security baselines are groups of Microsoft-recommended configuration settings. They’re meant to describe the security implications of those settings, so admins can understand what they’re changing, not just tick boxes.

You’ll commonly see them in areas like:

• Windows (including security baseline for Windows 10 and later)
• Endpoint and device management paths such as Intune
• Microsoft 365 security guidance through Microsoft 365 security baseline materials

How to use Microsoft recommendations correctly

Use Microsoft guidance as a strong starting point, not an automatic requirement. In your environment, a baseline you build might:

• adopt Microsoft-recommended settings where they fit
• adjust for app compatibility
• add exceptions for specific workloads
• align the approach with your risk tolerance

Also, remember Microsoft baselines are one implementation of the general baseline idea. Your program can use other inputs too, like internal standards, compliance requirements, threat intelligence, and vendor constraints. The goal is consistency and documented approval, not simply copying defaults.

How to perform a security baseline assessment

A security baseline assessment checks whether your systems match the baseline you approved. The basic workflow looks like this:

1. Pick the baseline and scope

• Which baseline document are you testing?
• Which system types, device groups, user groups, or application sets are in-scope?

1. Define the expected state

• Use the approved settings/controls from the document.
• Make sure admins understand which items are mandatory versus exceptions.

1. Collect current configuration evidence

• Review the actual device/system configuration.
• Use your existing inventory and management methods (for Microsoft environments, that might involve your Microsoft management stack).

1. Compare actual vs approved

• Identify gaps (missing settings, wrong values, or disabled protections).
• Flag exceptions that are documented but still working as intended.

1. Prioritize fixes

• Start with gaps that increase risk the most.
• Make sure fixes don’t break critical business apps or workflows.

1. Report results in business language

• Security teams need technical detail.
• Business leaders often want plain language: risk areas, systems affected, and what it would take to close gaps.

If you’re using the Microsoft baseline approach, this assessment step is also where you confirm whether your environment actually matches the Microsoft-recommended state, or where it diverges and why.

Security baseline examples and common implementation questions

A Security baseline example doesn’t have to be elaborate. It should be specific enough that someone could implement it.

Here are common example shapes:

Example 1: Standard endpoint profile

• Applies to: Windows 10 and later endpoints
• Contains: Approved OS security feature settings and configuration values
• Expected outcome: Endpoints should ship/operate in a consistent secure state

Example 2: Microsoft 365 access and protection expectations

• Applies to: User groups and Microsoft cloud resources
• Contains: Approved security-related configuration choices
• Expected outcome: Consistent security posture across user populations

Example 3: Minimum controls by system impact (control baseline)

• Applies to: Information systems categorized by low-, moderate-, high-impact
• Contains: A minimum set of required security controls
• Expected outcome: Higher-impact systems receive stronger baseline control coverage

Common implementation questions

1) “Do we need a baseline for everything?”

Not always. Start with the system types that matter most and where configuration drift is most likely, then expand as you can maintain it.

2) “Are Microsoft baselines mandatory?”

No. They’re Microsoft-recommended settings. You decide what matches your risk tolerance and requirements.

3) “What’s the difference between ‘approved settings’ and ‘controls’?”

Settings are the configuration you apply. Controls are the required security actions or safeguards, often tied to impact level in a security control baseline. Controls can drive the settings you approve.

4) “How do exceptions work?”

A baseline should include a way to record exceptions. If something can’t be changed because of a dependency, document it clearly and add a timeline or compensating safeguard where possible.

5) “Can baselines apply to users and apps?”

Yes. Baselines can cover security-related expectations for users, like access and authentication behavior, and for applications, like secure configuration expectations.

---

Before you change anything, review your current “approved” configuration state. Then check whether you already have a documented baseline for each system type you manage. If you don’t, create a security baseline document (or adapt one from your Microsoft materials) for every major category you support.