A new employee receives a laptop, accesses Microsoft 365, and begins working within an hour. That speed is useful, but it can also conceal risk if every account, device, and application is configured differently. Learning how to set security baselines gives your business a repeatable starting point: the minimum protections that should be present before users, systems, and data enter day-to-day operations.
For small and medium-sized businesses, a baseline is not an enterprise-sized rulebook that nobody can maintain. It is a practical agreement on what “secure enough to operate” means for your organization, backed by settings, ownership, monitoring, and a process for fixing exceptions.
Why security baselines matter beyond compliance
Without a baseline, security decisions tend to happen one ticket at a time. One employee uses multifactor authentication, while another has an older account configuration. One laptop encrypts its drive automatically, while another has missed updates for months. Each issue may appear minor in isolation. Together, they create gaps that attackers and operational failures can exploit.
A well-designed baseline brings consistency to the controls that matter most. It makes onboarding faster because approved settings can be applied repeatedly. It makes offboarding safer because access removal follows a defined process. It also improves incident response: when a device or account falls outside the expected standard, the team has a clear reference point for remediation.
The goal is not to eliminate all risk. That is neither realistic nor cost-effective. The goal is to reduce avoidable risk, prioritize the systems that matter most, and give business leaders confidence that essential controls are working consistently.
How to set security baselines in a practical way
Start with the business services your team relies on, then turn security expectations into settings that can be checked and maintained. The following approach keeps the work focused on measurable outcomes rather than generic policy language.
Define the scope around critical business operations
Begin by identifying the assets and services that support everyday work. For many growing businesses, this includes employee laptops, mobile devices, business email, Microsoft 365 identities, shared files, cloud applications, network equipment, and backup systems.
Do not try to standardize every system at once. Start with the assets that hold sensitive data, enable financial activity, provide access to customer information, or would interrupt operations if compromised. Email and identity systems are usually high priorities because a single stolen credential can lead to fraud, data exposure, or wider access to cloud services.
Document who owns each area. Security baselines fail when everyone assumes someone else is responsible for patches, account reviews, backup checks, or alert response. A named owner does not need to perform every technical task, but they should be accountable for ensuring it happens.
Assess what you have before deciding what must change
A baseline should reflect your actual environment, not an idealized one. Inventory active user accounts, administrative accounts, devices, applications, data locations, and current security tools. Review whether former employees still have access, whether devices are managed, and whether backups can be restored successfully.
This assessment often reveals simple but consequential issues: shared administrator credentials, unsupported operating systems, unmanaged personal devices, or cloud accounts that were created outside the normal onboarding process. Addressing these known weaknesses usually delivers more value than adding a new security product without fixing its underlying configuration.
Risk should guide the order of work. A company handling payment data or confidential client files may need stricter access controls and logging than one using cloud tools only for internal collaboration. Likewise, a team with remote workers may place greater emphasis on endpoint management, device encryption, and secure remote access.
Establish minimum controls by security domain
Your baseline should state what is required, how it is measured, and what happens when a system does not comply. Avoid vague requirements such as “keep systems secure.” A useful baseline specifies the expected condition.
For most small and medium-sized businesses, the core domains include:
- Identity and access: Multifactor authentication is required for business accounts, especially administrative accounts. Access is assigned according to job responsibilities, and privileged access is limited and reviewed regularly.
- Endpoint protection: Company devices use supported operating systems, approved endpoint protection, drive encryption, screen-lock settings, and automatic security updates.
- Email and collaboration: Email security settings help block malicious attachments, spoofing, and suspicious links. Sharing rules for files and collaboration spaces are limited to appropriate users.
- Data protection and recovery: Critical systems and data are backed up according to business needs, with restore testing performed on a scheduled basis. A backup that has never been tested is an assumption, not a recovery plan.
- Monitoring and response: Security alerts are reviewed, important events are retained, and there is a defined process for investigating, containing, and documenting incidents.
These controls should be adapted to your environment. Requiring device encryption is sensible for portable laptops containing business data. Applying the same requirement to a specialized legacy device may not be possible immediately. In that case, document the exception, identify compensating controls, and set a timeline for resolution rather than quietly accepting the gap.
Convert policy into enforceable configurations
A policy is useful only when it leads to consistent action. The next step is to translate each baseline requirement into technical settings, operational tasks, or both.
For example, “all users must use multifactor authentication” should become a configuration that enforces multifactor authentication, a process for enrolling new users, and a report that identifies accounts not covered by the policy. “Devices must be patched” should define update deadlines, acceptable deferral periods, and the action taken when devices remain out of compliance.
Automation is especially valuable here. Managed identity, endpoint, and backup platforms can apply standard configurations during onboarding and report deviations afterward. Security tools, including Acronis cybersecurity capabilities where appropriate, can also support protection, backup oversight, and remediation workflows from a more centralized operating model.
The right level of automation depends on your internal resources. Fully automatic enforcement can reduce human error, but it needs testing to avoid disrupting a business-critical application. Start with a pilot group, validate the impact, then expand the standard in phases.
Build exceptions into the process, not around it
Exceptions are unavoidable. A legacy accounting application may require an older component. A senior executive may need temporary access for a business transaction. A vendor may require limited access to support a system. The problem is not the exception itself. The problem is an exception with no owner, expiry date, or review.
Record each exception with the affected asset, business reason, risk, compensating controls, approver, and review date. This creates transparency for leadership and prevents temporary workarounds from becoming permanent vulnerabilities.
A practical baseline also distinguishes between urgent remediation and planned remediation. A compromised account or unprotected internet-facing system needs immediate attention. A lower-risk configuration gap may be scheduled into normal IT work, provided it is tracked and does not remain unresolved indefinitely.
Measure compliance and improve the baseline over time
Security baselines are operational controls, not one-time projects. Review compliance on a regular schedule and use the results to prioritize work. Useful measures include the percentage of users protected by multifactor authentication, the percentage of managed devices with current patches, the number of inactive accounts, backup success rates, restore-test results, and open exceptions past their review dates.
Reporting should be understandable to both technical teams and business leaders. Instead of presenting a long list of alerts, show which controls are meeting the standard, where the largest gaps remain, who owns remediation, and what business risk is affected. This turns security into a managed business function rather than a technical black box.
Review the baseline after major changes as well, such as a move to a new cloud platform, a merger, a shift to remote work, or a security incident. Controls that were adequate for a ten-person company may not be sufficient when the organization has multiple locations, more sensitive data, or more complex vendor access.
A security baseline works best when it becomes part of normal operations: every new user is onboarded consistently, every departing user is removed promptly, every device is checked against expected settings, and every exception has a clear path to closure. That discipline gives a growing business more than stronger defenses. It gives the business a dependable way to grow without losing control of its technology environment.