What Is a Security Baseline (and Why Your MSP Should Have One)?

When you bring on a new managed IT provider, one of the first questions to ask is: “What does every client get as standard?” If the answer is vague — “we assess each environment individually” or “it depends on your needs” — that should give you pause.

A security baseline is the set of controls, configurations, and policies that every client environment receives before anything else. It is the minimum standard. The foundation that everything else builds on.

At Tarbh Tech, our Security Baseline is not optional and not customised. Every client, every tier, every environment gets the same core protection. This guide explains what that baseline includes, why standardisation matters, and how to evaluate whether your current provider has something comparable.

Why consistency matters

The idea is simple: security should not depend on which engineer happened to set up your environment.

In many managed IT operations, each client environment is configured slightly differently. One engineer prefers a particular approach to Conditional Access. Another has a different opinion on email filtering rules. Over time, the provider ends up managing dozens of environments, each with its own quirks, undocumented exceptions, and inconsistencies.

This creates several problems:

Gaps emerge silently. If there is no standard to measure against, it is hard to know when something is missing. A client might not have MFA enforced on admin accounts simply because no one checked — and no standard required it.

Knowledge becomes tribal. When environments are unique, only the person who built them fully understands them. Staff changes, holiday cover, and incident response all become harder.

Quality varies with workload. When things get busy, corners get cut. Without a defined baseline, there is no floor — the quality of security depends on how much time the engineer had that week.

Auditing is difficult. If every environment is different, you cannot audit them against a common standard. Compliance frameworks like NIS2, ISO 27001, and Cyber Essentials all assume a baseline exists.

A standardised security baseline solves these problems by defining exactly what “secure” means in your environment and deploying it consistently.

What our Security Baseline includes

Our baseline covers six domains. Each is deployed to every client environment within the first two weeks of onboarding.

1. Identity and access control

This is the foundation of everything else. If someone who should not have access gets into your systems, nothing else matters.

• Multi-factor authentication (MFA) enforced for all users, with no exceptions. Security defaults or Conditional Access policies ensure MFA cannot be bypassed.
• Conditional Access policies that restrict access based on conditions: device compliance, location, risk level, and application. A sign-in from an unknown device in an unusual location triggers additional verification or blocks access entirely.
• Admin account protection with dedicated admin accounts separate from daily-use accounts, privileged role time-limiting, and break-glass emergency access procedures.
• Password policy aligned with current NIST guidance: no mandatory periodic rotation (which encourages weak passwords), minimum 14 characters, and banned common passwords.

2. Device management

Unmanaged devices are blind spots. If you cannot see a device, you cannot secure it.

• Microsoft Intune enrolment for all company devices — laptops, desktops, and mobile devices that access company data.
• Compliance policies that define minimum security requirements: OS version, encryption enabled, antivirus active, firewall on. Non-compliant devices are blocked from accessing company resources.
• Configuration profiles for consistent settings: BitLocker encryption, Windows Hello for Business, screen lock timeout, and automatic updates.
• Application management including approved app lists and the ability to remotely wipe company data from lost or stolen devices.

3. Email security

Email is the primary attack vector for most businesses. Over 90% of successful cyber attacks start with a phishing email.

• Exchange Online Protection with enhanced anti-phishing policies targeting impersonation of executives and key suppliers.
• Safe Attachments that detonate suspicious attachments in a sandbox before delivery.
• Safe Links that scan URLs at time of click, protecting against delayed-activation malicious links.
• Anti-spam policies tuned to the organisation’s communication patterns, with quarantine for suspect messages and admin review.
• DMARC, DKIM, and SPF configured to prevent email spoofing of your domain — protecting both you and your contacts.

4. Data protection

Protecting data in transit, at rest, and in use.

• BitLocker encryption on all Windows devices, with recovery keys escrowed to Azure AD for secure recovery.
• Information protection labels for classifying sensitive documents (Internal, Confidential, Restricted).
• Data Loss Prevention (DLP) policies that prevent accidental sharing of sensitive data — credit card numbers, PPS numbers, medical records — via email or cloud storage.
• External sharing controls on SharePoint and OneDrive, restricted to approved domains where appropriate.

5. Backup and recovery

Security is not just about preventing attacks — it is about recovering from them.

• Microsoft 365 backup covering Exchange mailboxes, SharePoint sites, OneDrive files, and Teams data. Microsoft’s native retention is not backup — we use dedicated backup tooling with independent storage.
• Defined retention periods with daily backups retained for 30 days and monthly snapshots for one year.
• Tested restores — we do not just verify backups exist, we periodically test that data can actually be restored. An untested backup is not a backup.

6. Monitoring and alerting

You cannot respond to what you cannot see.

• Security alerting from Microsoft 365 Defender, Azure AD Identity Protection, and Intune.
• Sign-in monitoring for risky sign-ins, impossible travel, and anomalous behaviour patterns.
• Admin activity logging with audit trails for all privileged operations.
• Automated response for common threat patterns — risky sign-ins trigger MFA challenges or session revocation automatically.

Measuring the result: Microsoft Secure Score

Security baselines need to be measurable. Saying “we take security seriously” is not evidence. Microsoft Secure Score provides that evidence.

Secure Score is Microsoft’s built-in security posture assessment. It evaluates your Microsoft 365 environment against hundreds of security recommendations and generates a percentage score. The score reflects how many recommended security controls are actually deployed.

Here is why the number matters:

• Industry average Secure Score: 50.6% — meaning the average organisation has deployed roughly half the recommended security controls.
• Tarbh Tech client average: 77.7% — a 27-point gap that represents real, deployed security controls.

That 27-point difference is not theoretical. It is the tangible result of our Security Baseline: MFA enforced, Conditional Access active, devices managed, email filtered, data protected, backups running. Every control that pushes the score up is a control that reduces your attack surface.

We publish this number because it is verifiable. You can log into your own Microsoft 365 security centre and check your Secure Score right now. If your MSP cannot tell you what your score is — or it is significantly below 77% — that tells you something about the security baseline they are operating with.

How to evaluate your current provider

If you already have a managed IT provider, here are the questions to ask:

1. What is your security baseline? Can they describe a specific, documented set of controls that every client receives?
2. What is our Secure Score? Can they tell you the number without looking it up?
3. Is MFA enforced for all users? Not “available” or “recommended” — enforced, with no exceptions.
4. Are Conditional Access policies active? What conditions do they evaluate?
5. Are all devices managed? Can they show you a compliance report?
6. What is your backup and recovery approach? When was the last restore test?
7. Is this documented? Can they share the baseline document?

If the answer to any of these is vague, hesitant, or “it depends on the client,” you may not have a security baseline — you have an ad-hoc configuration that varies from environment to environment.

How a security baseline evolves

A security baseline is not a static document. It evolves as threats change, as technology platforms add new capabilities, and as regulatory requirements tighten.

At Tarbh Tech, our baseline is reviewed quarterly. When Microsoft introduces a new security feature in Defender or Entra ID, we evaluate whether it should become part of the standard deployment. When a new threat pattern emerges — a novel phishing technique, a new ransomware strain targeting a specific vulnerability — we assess whether our baseline controls address it.

When the baseline is updated, the change rolls out to all client environments. This is one of the most significant advantages of standardisation: an improvement developed for one client benefits everyone. The engineering effort to evaluate, test, and deploy a new control happens once, and the result is multiplied across the entire client base.

This contrasts with ad-hoc environments, where improvements happen client by client, often triggered by incidents rather than proactive assessment. One client gets a new control after a near-miss; another does not until they have their own incident months later.

The regulatory alignment

Security baselines are not just operationally sensible — they increasingly map to regulatory requirements.

NIS2 requires “appropriate and proportionate technical, operational, and organisational measures” for cybersecurity risk management. A documented, measurable security baseline is precisely that — it demonstrates that you have defined what “appropriate” means and applied it consistently.

Cyber Essentials and Cyber Essentials Plus (the UK certification that many Irish businesses pursue, particularly those with UK clients) map directly to baseline controls: firewalls, secure configuration, access control, malware protection, and patch management.

ISO 27001 requires documented information security controls with regular review and measurement. A security baseline with Secure Score tracking provides both the controls and the measurement.

GDPR Article 32 requires “appropriate technical and organisational measures” to ensure security appropriate to the risk. A security baseline that covers encryption, access control, data protection, and backup demonstrates compliance with this requirement.

For businesses that need to demonstrate compliance with any of these frameworks, a documented security baseline is not optional — it is the starting point for any certification or audit.

Ad-hoc security versus baseline security

The difference between ad-hoc and baseline-driven security is not about the individual controls. Any competent engineer can deploy MFA or configure Safe Links. The difference is in the approach:

Ad-hoc: Each environment is configured based on the engineer’s judgement, the client’s budget, and available time. Controls are added reactively — often after an incident or audit finding. There is no standard to measure against, and no guarantee that what one client has, another does too.

Baseline: Every environment starts from the same foundation. Controls are deployed proactively as part of onboarding, measured against a defined standard, and audited regularly. The baseline evolves over time, and when it does, the improvement rolls out to all clients.

The baseline approach costs more upfront in engineering time. It requires documentation, process discipline, and a commitment to consistency over convenience. But it produces demonstrably better security outcomes — and it scales.

What a baseline does not cover

It is worth being clear about what a security baseline is not. It is the foundation — not the entire building.

A security baseline does not replace:

• A full security audit or penetration test. The baseline establishes controls; testing validates they work under pressure.
• Compliance certification. The baseline supports compliance frameworks, but certification requires additional documentation, processes, and often third-party assessment.
• Incident response. The baseline reduces the likelihood and impact of incidents, but you still need a response plan for when something gets through.
• Security awareness culture. Technology controls catch most threats, but human error remains the largest attack surface. Ongoing training complements the technical baseline.

Understanding these boundaries helps set the right expectations. The baseline is the floor that ensures everyone starts from a strong, consistent position. Additional layers of security — advanced threat hunting, security operations centre (SOC) monitoring, regular penetration testing — can be added on top for organisations that need them.

The bottom line

A security baseline is not a nice-to-have. It is the foundation of competent managed IT. If your provider cannot describe their baseline in concrete terms, measure it with a verifiable metric, and demonstrate it with evidence — they are operating on intuition rather than engineering.

Every Tarbh Tech client gets the same baseline. Every environment is measured against the same standard. Every Secure Score is visible to the client. This is what security-first managed IT looks like in practice: consistent, measurable, and transparent.