MSP Configuration Drift: How ISO 27001 A.8.9 Secures Baselines & Controls

The MSP configuration drift problem you can’t see yet

Configuration drift is when customer environments quietly move away from an agreed “known good” state until something breaks or audits become difficult. For a managed service provider, that drift is multiplied across every tenant you support, because the same small tweak pattern can appear hundreds of times before anyone spots and corrects it.

Small configuration inconsistencies quietly grow into big operational and security problems.

Where drift really hides in a typical MSP stack

Configuration drift hides in all the places your engineers touch every day, and it rarely announces itself until it has already created a mess. The more platforms you operate, the more opportunities there are for subtle differences to creep in, stay unnoticed and undermine your “standard” services.

Common sources include:

Remote monitoring and management policies for different customer groups.
Identity platforms and conditional access rules across tenants.
Firewalls, VPNs and network security appliances.
Cloud workloads and infrastructure‑as‑code templates.
SaaS admin portals and legacy automation scripts.

In practice that looks like slightly different password or multi‑factor authentication settings across tenants, inconsistent logging configurations, one‑off firewall rules added during an incident or a handful of device profiles that no one remembers creating. None of those is dramatic on its own, but together they create a situation where you can no longer confidently describe how a particular service is configured for every client.

A simple example is identity security. On paper, you may say “all customer tenants enforce multi‑factor authentication for all privileged accounts”. In reality, you might discover that some tenants still rely on legacy protocols, some have weaker conditional access and others have ad hoc exclusions for senior staff. Those small variations become hard to track and even harder to defend when something goes wrong.

How invisible drift erodes margin, trust and sleep

Configuration drift slowly undermines your margins, customer trust and engineers’ quality of life by turning “standard” services into hidden one‑offs. The financial impact shows up as rework, escalations and extended outages rather than a neatly labelled cost line, so it is easy to underestimate until patterns become painful.

Over time engineers spend late nights trying to reproduce issues that only occur on a subset of tenants, rolling back half‑documented changes and calming customers who are rightly asking why apparently identical environments behave differently. That means lower gross margins on “standard” services, because they are no longer truly standard. Your teams burn time reconciling configuration differences instead of delivering new value, while customers and internal stakeholders lose confidence in the idea of a “gold build” because reality never fully matches the paperwork or service catalogue.

Why configuration drift becomes a security and compliance problem

Configuration drift directly increases security and compliance risk by weakening controls in ways that are hard to see until after an incident. Independent post‑incident reviews of outages and breaches frequently show that simple configuration weaknesses and accumulated drift - such as unnecessary open ports, disabled logging, over‑permissive access rules or forgotten test settings left in production - were the primary control failures rather than exotic exploits, as highlighted in a range of incident review analyses. Those findings align with broader risk studies that classify configuration weaknesses and drift as major categories of control failure driving security and compliance incidents in multi‑tenant environments.

A majority of organisations in the 2025 State of Information Security report say they were directly impacted by at least one third‑party or vendor‑related security incident in the past year.

For an MSP working toward ISO 27001:2022, this matters because Annex A.8.9 expects configurations – including security configurations – of hardware, software, services and networks to be established, documented, implemented, monitored and reviewed. Practical interpretations of ISO 27001:2022 A.8.9 emphasise this full lifecycle view of configuration, rather than treating it as a one‑time setup task, and explain how those verbs translate into day‑to‑day configuration governance, as outlined in various practical interpretations of A.8.9. If baseline configurations exist only in theory, changes happen informally and monitoring is patchy, it becomes difficult to demonstrate genuine control of configuration risk across your customer base. That weakens your audit position and leaves you exposed to incidents triggered by variations you did not even know existed.

Book a demo

What ISO 27001:2022 A.8.9 really expects from configuration management

ISO 27001:2022 A.8.9 expects you to standardise, enforce and review secure configurations across all systems you manage. It effectively asks you to turn configuration from a set of ad hoc decisions into a governed lifecycle that can be explained, evidenced and improved. Verb‑to‑artefact mapping guidance for A.8.9 interprets this as a requirement to maintain consistent, reviewable secure configurations supported by clear records of how they are established, implemented, monitored and reviewed, rather than leaving them embedded only in individual engineers’ heads or tools, as discussed in verb‑to‑artefact mapping guidance for A.8.9.

The core requirement in simple, MSP‑friendly terms

Seen through an MSP lens, A.8.9 asks you to define, apply, control and review secure configurations across your managed estate. First, decide what “secure and appropriate configuration” means for the technologies and services you operate. Secondly, implement those configurations reliably for each relevant customer. Thirdly, control changes so that nothing significant is altered without some level of approval and traceability. Finally, monitor and periodically review configurations to detect unauthorised or risky changes and to adjust standards when technology or risk changes.

This is not just about servers. The wording covers hardware, software, services and networks, which means everything from firewalls and hypervisors to cloud subscriptions, SaaS tenants and identity providers. Modern control catalogues and governance patterns explicitly extend configuration management to cloud workloads, SaaS services and identity platforms, so including these alongside traditional on‑premise assets keeps your A.8.9 scope aligned with current best practice, as reflected in a range of cloud and SaaS configuration governance discussions. If the way a system is configured affects confidentiality, integrity or availability, it sits within the scope of A.8.9 and needs to be part of your configuration management storey.

The 2025 ISMS.online survey shows that customers increasingly expect suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 and emerging AI standards.

If the way a system is configured affects confidentiality, integrity or availability, it sits within the scope of A.8.9 and needs to be part of your configuration management storey.

How A.8.9 connects to other controls and your ISMS

A.8.9 only works in practice when it is integrated with asset management, change control, monitoring and risk management. You need a reliable asset inventory so you know which systems and services actually require configuration baselines. You need change management so that configuration changes are requested, assessed, approved and reviewed. You need monitoring so that configuration events are logged and meaningful deviations are detected. You also need risk management so that you can decide where strict baselines are essential and where some flexibility is acceptable.

For an MSP, configuration management should therefore be designed as part of the ISMS, not as a standalone engineering initiative. When configuration drift is treated explicitly as an information security risk, it becomes easier to justify investment in automation, to prioritise high‑impact areas and to explain to auditors how your controls work together to keep drift within acceptable bounds. Management reviews then become the place where you examine configuration metrics, incident trends and exception patterns to decide how A.8.9 and related controls need to evolve.

ISMS.online gives you an 81% Headstart from the moment you log on

ISO 27001 made easy

We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.

Get started

From one‑off fixes to strategic configuration baselines

Configuration management becomes manageable at MSP scale when you stop treating every environment as a one‑off and start working from agreed baselines. A baseline is simply an approved description of how a given class of system or service must be configured for you to consider it safe and supportable.

What a “secure configuration baseline” means in MSP practice

A secure configuration baseline for a managed service combines operating system settings, application parameters and security controls into a single, versioned reference. For example, you might have a baseline for “standard Windows server”, another for “hardened Windows server for regulated clients” and another for “standard Microsoft 365 tenant”, each with clear minimum expectations.

Each baseline defines the minimum set of security and operational settings you expect: password policy, logging, update behaviour, remote access rules, encryption options, monitoring agents and so on. Crucially, each baseline has a clear owner, an approval history and a review schedule. That turns “standard build” from an informal idea into a controlled artefact that can be shown to auditors and used by engineers with confidence.

Designing baselines that are both strong and realistic

Effective baselines balance security, performance and practicality so engineers can apply them consistently in real customer environments. You rarely start from a blank page: secure configuration guides, vendor best practice and industry benchmarks can act as sensible starting points, then be adjusted to suit your customer base and service model without becoming unrealistic.

If a baseline is too strict, engineers will be tempted to work around it to solve real‑world issues. If it is too loose, it will not meaningfully reduce risk. Involving both security and operations staff in baseline design helps avoid theoretical standards that cannot be maintained. It also creates a shared sense of ownership, which is vital when you begin to enforce those baselines systematically and use them as the reference point in audits and management reviews.

Making baselines machine‑readable and auditable

Baselines are most powerful when tools can execute them and auditors can understand them. Wherever possible, express baselines in formats that tools can consume as well as in human‑readable documents. That might mean group policy objects, device‑management profiles, infrastructure‑as‑code templates, firewall configuration templates or remote‑monitoring policy sets that can be deployed repeatedly.

At the same time, you still need a way to show auditors what your baselines are and how they are governed. That usually means storing baseline definitions, approvals and version history in a structured way, ideally linked into your ISMS. An ISMS platform such as ISMS.online can hold the narrative description, ownership records and review outcomes for each baseline while your technical tools store and apply the detailed configuration. Together, that combination gives you both operational control and audit‑ready evidence.

Building an MSP‑ready baseline hierarchy for multi‑tenant environments

In a multi‑tenant MSP, you need a hierarchy of baselines so services and customers inherit controls in a controlled and explainable way. A single global baseline is rarely enough, because different services, customer tiers and regulatory profiles need different levels of hardening and trying to handle all of that variation ad hoc quickly becomes unmanageable.

Separating global, service and customer layers

A three‑layer structure helps you separate MSP‑wide minimums, service baselines and customer‑specific variations. One effective pattern is to define three logical layers that work together rather than competing with each other.

MSP‑wide core baseline: – minimum controls you insist on for any managed environment.
Service or technology baselines: – specific baselines for firewalls, Microsoft 365, endpoints and similar services.
Customer‑level variations: – limited, documented deviations where a customer genuinely needs something different.

At the top sits the MSP‑wide core baseline: the minimum set of controls you insist on for any customer environment you manage, such as multi‑factor authentication for staff accounts, essential logging and standard remote access practices. Beneath that, each service or technology stack has its own baseline – for example, a standard firewall configuration or a standard Microsoft 365 security configuration. Finally, at the bottom, each customer can have a small number of documented variations where their needs genuinely differ from your standard tiers.

This hierarchy means that most settings are defined once and inherited, while true exceptions are explicit and traceable. When designed well, it lets you on‑board new customers quickly by assigning them to an existing service baseline and tier, rather than inventing a new configuration pattern each time.

Governing exceptions instead of creating chaos

Exceptions are inevitable, so you need a simple, controlled way to record and review them. No matter how good your baselines are, there will always be cases where a customer needs something different: a legacy application, a contractual obligation or a regulatory nuance that forces a deviation from your standard build.

Instead of treating exceptions as informal notes in tickets or chat threads, it is better to maintain a simple exception register. Each entry records what baseline is being deviated from, what the change is, why it is necessary, who approved it, what risk it introduces and when it should be reviewed again. That approach accepts that variation is sometimes needed but keeps it under control and visible to both management and auditors. It also gives you a way to spot patterns where the baseline itself may need to evolve.

Making the hierarchy visible to engineers and customers

A baseline hierarchy only works if engineers and customers can see which baselines apply and how they differ. Engineers need to know which baseline applies to a given tenant, what is inherited and what is special case. Customers – especially those with their own security or risk teams – need a clear explanation of what “standard” looks like and where they differ from it.

Simple diagrams and short textual summaries often work better than dense documents. For example, a one‑page view that shows the MSP core baseline, the service baseline and a handful of customer‑specific controls can do more to build trust than pages of raw configuration. That clarity also makes it easier to have sensible conversations about requested changes, because everyone can see the impact on the baseline model. When those summaries are linked back to your ISMS and A.8.9, you can also demonstrate that configuration decisions are part of a coherent, standards‑aligned design.

Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.

Book your demo

Implementing baselines with tooling, automation and enforcement

You only benefit from baselines when they are implemented through the tools your teams already use and kept close to “known good” by default. The goal is to move from “we know what good looks like” to “our systems actively keep things close to that standard unless we deliberately change them”.

Step 1 – Map baselines onto real tools

You start by mapping each baseline control to a concrete policy, profile, template or script in the tools you already operate. That gives you a clear bridge between a written baseline and the settings that actually shape customer environments every day.

Step 2 – Prefer desired state over quick scripts

You then favour desired‑state models that continually align systems with the baseline instead of relying on one‑off scripts and ad hoc edits, which tend to diverge silently over time.

Step 3 – Roll out changes safely and gradually

Finally, you build guard rails around enforcement so changes roll out in stages, are monitored closely and can be rolled back quickly if needed, rather than pushing high‑risk changes everywhere in one movement.

These steps give you a simple mental model for implementation, and the rest of this section looks at each area in more detail.

Mapping baselines onto your operational toolset

You implement baselines by mapping each configuration requirement onto specific policies, profiles or templates in your existing tools. Most MSPs already operate a mix of remote monitoring platforms, device‑management tools, cloud administration consoles and identity systems, and each of those can be harnessed to enforce part of a baseline in a repeatable way.

Typical mappings include:

Remote monitoring and management policies enforcing agents, patching and core services.
Device‑management policies enforcing password, encryption and compliance rules on endpoints.
Infrastructure‑as‑code templates standardising cloud network layouts and security groups.
Identity platforms enforcing multi‑factor authentication and conditional access policies.

The key is to map each element of a baseline to a specific enforcement mechanism. That mapping should be explicit: instead of assuming “the RMM takes care of it”, you document which policy, profile or template enforces each control. This not only improves operational clarity but also makes audit conversations smoother because you can show exactly how a baseline is realised.

Favouring desired state over one‑off scripts

Desired‑state tools are more reliable than one‑off scripts because they continually realign systems with your baselines. There will always be moments when a quick script feels like the fastest way to solve a configuration issue, but relying too heavily on one‑off scripts is a common source of drift that only becomes visible when something fails.

Someone may run a script against some tenants but not others, or forget to undo a temporary change once an incident is resolved. Over time, those small differences accumulate. A desired‑state model lets you declare how systems should look, and agents or pipelines continually compare actual state against that declaration. When they detect differences, they either alert or automatically converge back towards the desired configuration. This reduces reliance on individual memory, makes configuration more repeatable and helps keep environments aligned with baselines over time.

Building safety into enforcement

Safe enforcement means rolling out baseline changes in small, reversible stages rather than pushing everything everywhere at once. Automating baseline enforcement across many tenants introduces real power but also risk, because a mis‑configured template or policy can cause wide‑ranging outages if pushed everywhere in one go.

To avoid that, it makes sense to adopt the same safety practices used in modern software deployment rather than treating configuration as an all‑or‑nothing exercise. That usually includes phasing changes through environments or tenant groups, starting with low‑risk or internal tenants, monitoring closely for unexpected effects and having clear rollback plans. Change windows and communication plans are still important, but with good automation your changes can be smaller, more frequent and easier to reverse than large, infrequent “big bang” updates. That in turn makes auditors and customers more comfortable with the level of change happening across your estate.

Clarifying the boundary between tools and your ISMS

Operational tools enforce and monitor configurations; they do not, by themselves, deliver compliance with A.8.9. To satisfy ISO 27001, you also need governance: who owns which baselines, how changes are approved, how evidence is collected and how effectiveness is reviewed over time.

An ISMS platform adds value by providing the place to record policies, baselines, responsibilities, approvals, exceptions and review outcomes. ISMS.online, for example, links those governance elements to the outputs of your tools – such as configuration exports, change tickets and monitoring reports – so that you can show a complete storey from intent through implementation to verification. This combination of technical enforcement and structured governance is what turns configuration management into a robust control rather than a loose collection of good intentions.

Continuous drift detection, triage and remediation

Even with strong baselines and automation, configuration drift will still occur, so you need a repeatable way to spot it early and respond. People will make mistakes, vendors will change defaults and new requirements will appear faster than governance can adapt, so your aim is to manage drift rather than pretend you can eliminate it entirely.

Detecting drift in a multi‑tenant landscape

You detect drift by combining desired‑state checks, security monitoring and posture‑assessment tools across your tenants. Desired‑state tools can raise signals when actual configurations no longer match defined baselines. Security monitoring may highlight changes in exposed services or permissions. Cloud and SaaS platforms often provide configuration‑assessment or posture‑management capabilities that compare current settings against templates or best practice.

The important point is to have a deliberate strategy rather than a patchwork of alerts. Decide which systems and controls are high priority for drift detection, configure the relevant tools to watch them and ensure that signals are routed somewhere people will actually see them. For high‑impact areas – such as identity, external exposure and logging – continuous or very frequent checking is justified. For lower‑impact settings, periodic sampling may be enough to give you confidence.

Triage based on risk rather than noise

You need to rank drift by risk so teams fix serious deviations without drowning in minor alerts. Not every deviation from a baseline is equally important, and if every small difference generates an urgent ticket, teams will quickly become overwhelmed and start ignoring alerts, which defeats the purpose.

To avoid that, it helps to classify drift into a few simple categories:

Security‑relevant drift: – changes that weaken access control, disable monitoring or open new network paths.
Availability‑relevant drift: – changes that risk stability, performance or recoverability.
Compliance‑relevant drift: – changes that undermine contractual commitments or certification scopes.
Cosmetic drift: – harmless preference differences with no real risk impact.

Once each category has clear handling rules and target response times, your teams can focus effort where it really matters. Security and compliance‑relevant drift that affects many tenants or critical systems will usually deserve the fastest response. Cosmetic drift might only need attention when there is time, or when it points to deeper process issues.

Embedding drift handling into your service workflows

Drift events should feed into the same disciplined workflows you use for other operational signals so nothing is handled informally or forgotten. High‑risk drift might create an incident and a corresponding change request to restore or adjust the baseline. Repeated drift of the same type might trigger a problem‑management investigation, looking for weaknesses in the baseline design, tooling or training that need to be addressed.

Linking operational tools to your ISMS helps you keep this structured. When drift alerts, tickets, changes and problem records are all traceable back to specific baselines and controls, it becomes much easier to show auditors and customers that configuration management is under active, risk‑based control rather than being an ad hoc firefighting activity. You can also feed recurring drift patterns into the risk register and management review agenda so that A.8.9 is continually refined in response to real‑world experience.

ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

Book your demo

Evidence, metrics and audit‑ready reporting for A.8.9

To satisfy A.8.9 in a credible way, you need more than good intentions and a handful of screenshots. Auditors and customers will want to see evidence that configuration management is designed, implemented and operating effectively over time, and that you use results to improve rather than just to tick a box once a year.

Building an evidence chain that makes sense to outsiders

An effective evidence set for configuration management usually includes several layers that tell a coherent storey from policy to practice. At the top, you have policies and standards that state your expectations. Beneath those are the baseline definitions themselves, with owners, approval history and version information. Implementation evidence might include configuration exports, scripts, templates, monitoring policies or device profiles. Monitoring evidence shows how you check for drift or unauthorised change. Finally, review records demonstrate that you periodically reassess both baselines and their effectiveness.

The table below summarises the main evidence layers and what they demonstrate.

Evidence layer	What it shows	Typical examples
Policy and standards	Overall intent and expectations	Configuration policy, secure build standard
Baseline definitions	Approved “known good” configurations	Baseline documents, owners, version history
Implementation	How baselines are applied in practice	RMM policies, templates, device profiles
Monitoring and drift	How changes and deviations are detected	Drift alerts, logs, posture assessments
Review and improvement	How you learn and improve over time	Management reviews, exception reviews, action logs

Together these layers show that A.8.9 is designed, implemented, monitored and improved over time, not just documented once and forgotten. The most persuasive evidence chains make it easy for an outsider to follow the thread. They can start at the policy, see how it is translated into baselines, inspect a sample of real systems or tenants to confirm alignment and then see how deviations are handled. That is much easier when evidence is stored in a structured way, for example within an ISMS platform such as ISMS.online that links each artefact to the relevant control and risk so nothing is lost in mailboxes or shared drives.

Choosing metrics that prove control without overwhelming you

Metrics show that configuration management is active and improving, but too many indicators quickly become noise. A small number of well‑chosen measures is usually enough to demonstrate control and support decisions without creating unnecessary reporting overhead.

A strong majority of respondents in the 2025 State of Information Security report say the speed and volume of regulatory change are making compliance significantly harder to sustain.

Useful examples include the proportion of key assets that are covered by a defined baseline, the rate of unauthorised changes detected, the average time to remediate critical drift and the number of open exceptions past their review date. You can then feed these metrics into your management reviews alongside financial and service indicators. Over time they help you answer questions such as: Are you getting better at keeping tenants aligned with your baselines? Are you seeing fewer incidents tied to misconfiguration? Do you need to invest more in automation or training for particular services?

Because ISO 27001 emphasises continual improvement, being able to show trends and actions based on those trends is just as important as hitting specific target numbers at a single point in time. Governance guidance on ISMS management review indicators echoes this, stressing that management should focus on direction of travel and the decisions taken, not just on whether a single metric cleared a threshold, as reflected in many management‑review metrics examples. ISMS.online can support this by linking metrics and actions directly to the underlying controls, so you have one place to review progress and decide what should change next.

Communicating configuration assurance to customers

Many of your customers will not want to see low‑level configuration detail, but they will want assurance that you have configuration management under control. Customer‑reporting studies and examples suggest that concise, high‑level configuration‑assurance reporting improves trust and reduces repeated questioning, especially when it follows a consistent format rather than ad hoc responses to each query, as shown in various configuration‑assurance reporting examples. Clear, periodic summaries can strengthen relationships and reduce repetitive questionnaire work that otherwise eats into your margins and your team’s time.

In the 2025 ISMS.online State of Information Security survey, around 41% of organisations named managing third-party risk and tracking supplier compliance as a top information-security challenge.

Those summaries might highlight which services are covered by standard baselines, key changes in configuration posture over the period, significant drifts that were detected and resolved and any open exceptions under review. The aim is to give customers enough insight to trust your practices without overwhelming them with raw data. When your internal evidence is already structured around A.8.9 and related controls, producing such customer‑facing views becomes largely a matter of selecting and reshaping information you already maintain rather than assembling it from scratch every time someone asks.

Book a Demo With ISMS.online Today

ISMS.online is a good fit when you want configuration management to be governed, audit‑ready and still practical for your engineers. Instead of hunting through shared drives, ticket systems and admin consoles when an audit or incident lands, you have one place where policies, baselines, owners, approvals, exceptions, change records and review outcomes are connected and easy to navigate.

Almost all organisations in the 2025 ISMS.online survey list achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority for the next few years.

What you can expect from an ISMS.online walkthrough

A short walkthrough helps you see how your current configuration processes map onto ISO 27001 A.8.9 and related controls. You can explore how policies, baselines, asset records, risk treatments and change approvals join up so configuration decisions, tools and evidence all support a single, consistent storey.

For MSP leaders, that means understanding which services and customer tiers are covered by defined baselines, who owns each part of A.8.9 and where the main risks and gaps sit today. For compliance and security leads, it means seeing how each configuration control and piece of evidence can be mapped directly to Annex A.8.9 and other relevant controls, so you can answer auditor questions with confidence rather than scrambling to assemble documentation.

Turning A.8.9 concepts into your MSP configuration plan

A conversation about ISMS.online is most useful when you use it to translate the ideas in this guide into concrete next steps. You bring your current service catalogue, configuration tools and certification goals; the focus is then on working out how to use governance, baselines and automation to strengthen control without slowing your engineers down.

For architects and practitioners, that often means linking your remote monitoring, device‑management and cloud tooling into workflows that capture the right evidence automatically, rather than relying on manual screenshots and spreadsheets. For management, it means agreeing a phased plan that improves configuration baselines and drift controls where risk is highest first, while keeping effort realistic. If that kind of structured, standards‑aligned approach to configuration management feels like the right direction, choosing ISMS.online as your ISMS platform is a natural next step when you are ready to act.

Book a demo

Frequently Asked Questions

What does ISO 27001:2022 A.8.9 really expect from an MSP running many client environments?

ISO 27001:2022 A.8.9 expects your MSP to treat configuration management as a defined, repeatable service, not as a set of “standard builds” people remember differently. You need to show how you define secure configurations, enforce them at scale, watch for drift, and improve them as technology and risk evolve.

How should you interpret A.8.9 through an MSP lens?

Read the control as five linked expectations that fit naturally with how you already work:

Established: – you agree what “safe and supportable” means for each major service you manage: servers, cloud tenants, firewalls, VPNs, backup platforms, identity and access.
Documented: – you capture those decisions as short, testable baselines with clear scope, owners, non‑negotiable settings, version history and review dates.
Implemented: – you use your RMM, MDM, cloud policy sets, infrastructure templates and scripts to roll those baselines into production across all relevant tenants.
Monitored: – you run posture checks, reports and targeted alerts so you can see when reality drifts away from the standard you agreed.
Reviewed: – you feed in lessons from incidents, vendor changes, customer feedback and audits so baselines and workplans keep pace with risk.

Because A.8.9 sits alongside controls on assets, change, logging and incidents, auditors and larger customers will expect configuration to be threaded right through your ISMS, not hidden in a runbook or a senior engineer’s head. A simple test is whether you can start from a specific risk – say, exposed remote access or over‑privileged accounts – and then trace it:

to the baseline that defines what “good” looks like
to the tools and templates that enforce it
to tickets, change records and reviews that show how you respond when things drift

If you can walk that chain quickly for a few representative services, A.8.9 looks embedded rather than cosmetic. ISMS.online helps you make that storey repeatable by giving you one place to link the wording of A.8.9 to baselines, owners, tasks and evidence, so you are not rebuilding the explanation from scratch every time an auditor, vendor programme or prospect asks, “show me how you manage configuration across your customers.”

How can an MSP create configuration baselines engineers respect and auditors can test?

You earn trust from both engineers and auditors when baselines are short, specific and testable. An engineer should be able to decide in minutes whether a system fits a pattern, and an auditor should be able to sample a few systems and reach the same conclusion without argument.

What turns a “standard build” into an ISO‑ready baseline?

Instead of hundreds of one‑off build documents, most MSPs work best with a small set of named patterns per major service, such as:

“Windows Server – general business workloads”
“Windows Server – hardened for finance and healthcare”
“Microsoft 365 tenant – office users”
“Microsoft 365 tenant – admins and executives”
“Firewall policy – branch office internet breakout”
“Firewall policy – internet‑facing services”

For each pattern, a useful baseline answers three questions.

1. Which systems are covered?

Reduce grey areas by spelling out scope:

Platform and minimum supported versions
Identity approach (local accounts, on‑prem AD, Entra ID, hybrid)
Security agents and monitoring tools that must be present
Backup and recovery expectations (including any RPO/RTO targets)
Allowed and disallowed remote‑access methods

2. What are the non‑negotiable settings?

List the controls you are not prepared to compromise on, for example:

Authentication: – MFA on all administrative access, password and session rules, conditional‑access expectations
Network posture: – open and blocked ports, TLS versions, segmentation rules
System hardening: – services disabled, local admin rules, lock‑screen behaviour
Logging: – minimum log sources, retention periods, and where logs are sent
Patching: – maximum patch age, maintenance windows, reboot policy

3. Who owns it and how is it kept current?

Make it clear that this is a living standard, not a one‑off project:

Named owner and approver (by role, not just an individual’s name)
Version number and change notes for material updates
Due date for the next review, plus a record of the last one actually done

If your “standard build” only lives in a senior engineer’s memory or on a static wiki, it is hard to show that configuration is controlled. Storing baselines in ISMS.online gives you a controlled space to keep definitions, approvals and review history together, link each baseline to the risks it addresses and the services it supports, and give auditors a clean sample set rather than a tangle of informal notes.

How can an MSP control configuration drift across many tenants without drowning in alerts?

You keep configuration drift under control by making your baseline the easiest way to work, using tools to pull environments back towards that state, and treating meaningful deviations as normal work items, not background noise.

How can you use the tools you already own more deliberately?

Most MSPs already pay for capable RMM, MDM and cloud‑management platforms. A.8.9 is less about buying new tools and more about using what you have in a structured way:

Enforce desired state continuously: – configure policies and profiles so endpoints, tenants and infrastructure self‑correct towards your standard, instead of relying on last‑minute scripts before an audit.
Start new tenants aligned: – build from standard templates for Microsoft 365, endpoint profiles and firewall configurations so new environments begin close to your baseline rather than as unique builds nobody wants to change.
Focus on settings that really move risk: – give real‑time visibility and higher alert priority to areas where drift quickly leads to incidents, such as privileged access, external exposure, backup coverage and critical logging gaps. Push lower‑impact items into scheduled posture reviews or quarterly assessments so engineers do not start ignoring their tools.
Route drift into existing control loops: – categorise deviations as security, availability, compliance or operational issues so they land in the right queues with sensible priority. Turn repeating patterns into problem records and baseline adjustments rather than endlessly fixing individual symptoms.

A quick self‑check is to take a sensitive area such as administrative access to firewalls or tenant configuration. If you can show, in a short walkthrough, where the baseline lives, which controls in your tools enforce it, how drift appears in reports or alerts, and how fixes and exceptions are logged, you look in control. If the explanation leans heavily on “our senior engineer knows how it’s done,” your A.8.9 storey will feel fragile to an auditor or an enterprise customer.

ISMS.online helps you tie this together by linking control A.8.9 to specific baselines, tool outputs, tickets and review records. That way, configuration drift management becomes part of your normal service rhythm and reporting, not an uncomfortable scramble every time an assessment or vendor programme asks you to prove how you keep environments in line.

How should an MSP adapt configuration baselines for regulated or high‑impact customers without creating unmanageable complexity?

Regulated clients and high‑impact workloads need stricter controls, but maintaining a bespoke build for every tenant quickly becomes unworkable. A practical answer is a tiered model where you have one MSP‑wide floor, a few hardened variants, and a small number of clearly controlled exceptions.

What does a workable tiered model look like?

For most MSPs, a pattern like this is enough to balance flexibility and control.

Start from an MSP‑wide baseline for all customers

This is the non‑negotiable minimum every environment must meet:

Supported operating systems and firmware
MFA for your staff and administrative access to management planes
Core logging and backup coverage for key systems
Reasonable patch cadence and secure remote‑access expectations

Add risk‑based tiers for your main platforms

For each major service area, define a small set of tiers that inherit from the MSP baseline and add protections where risk justifies it, such as:

Microsoft 365: standard / enhanced / regulated
Servers: standard / hardened
Network edge: small business, critical internet‑facing, payment or regulated data
Remote access: general staff, administrators, external vendors

Tiers might introduce tighter conditional access for executives, deeper logging and monitoring for regulated workloads, or stricter network segmentation for critical systems, always with a stated reason.

Capture real‑world variation as overlays or exceptions

Some customers will still need something different:

Legacy applications that cannot tolerate the full hardened profile
Extra conditions set by a particular regulator or industry scheme
Temporary measures while projects move away from unsupported platforms

Instead of leaving these as unwritten understandings between engineers and account managers, record them as overlays or exceptions with clear justification, risk treatment and review dates. That makes it much easier to answer “why is this environment different?” with a concise, evidence‑backed explanation.

ISMS.online is designed to support that structure. You can model baseline families and overlays, link them to specific customers and services, and keep approvals and review history together. When a regulator, auditor or major customer wants to see how you treat regulated or high‑impact environments, you can show, on a single screen, which controls they share with other tenants, which additional protections they receive and which conscious exceptions you are carrying.

What kind of evidence convinces auditors and customers that A.8.9 is genuinely embedded?

Most auditors and security‑savvy customers accept that no environment is flawless. What they look for is a coherent, traceable chain from intent to implementation to improvement. A lean, well‑chosen evidence pack for A.8.9 demonstrates that chain without burying anyone in screenshots.

How can you assemble an A.8.9 evidence storey that stands up to scrutiny?

It often helps to think in four layers and prepare a small number of good examples for each.

Show where configuration management lives in your ISMS:

An information security policy or standard that refers clearly to configuration management and to A.8.9
A short procedure or ISMS “project” that explains how you establish, implement, monitor and review baselines across your main services

2. Baselines and implementation

Prove that decisions became real configurations:

A few sample baseline documents with scope, non‑negotiable settings, owners, versions and recent review dates
Examples of RMM policies, MDM profiles, cloud templates or firewall configurations that apply those baselines for actual customers

3. Monitoring, drift and change

Demonstrate that you can see what is happening and respond:

Posture dashboards or reports that highlight both conformity and material drift in key areas
A short set of tickets or change records for meaningful deviations, showing who raised them, who approved any exception and how they were resolved

4. Review and improvement

Close the loop with evidence of learning:

Extracts from internal audits, service reviews or management‑review meetings where configuration risks and results were discussed
Brief records showing how vendor advisories, near‑misses or customer feedback led to baseline changes or monitoring adjustments

You do not need to assemble this chain for every endpoint or customer. A handful of well‑documented paths that start from A.8.9, pass through baselines and tooling, and end in tickets and review notes are often enough to satisfy an auditor or programme assessor.

ISMS.online helps by letting you link A.8.9 directly to policies, baselines, tasks, tool outputs and review artefacts. Instead of hunting across drives and mailboxes, you can philtre for a specific control and pull a complete, consistent storey whenever someone asks how you govern configuration across your managed environments.

How does ISMS.online turn configuration management from a hidden chore into a visible MSP capability?

Most MSPs already have the technical building blocks for A.8.9: RMM, MDM, cloud‑management tools and firewall platforms. The gap is usually a management system that explains how those pieces fit together, who is accountable and how you adapt over time. When you model configuration management in an ISMS, it stops being a background task and becomes a capability you can talk about with confidence in audits, RFPs and renewal meetings.

What changes when you model A.8.9 inside an ISMS?

Three practical shifts usually follow quite quickly.

You link standard wording to day‑to‑day work

You can map the text of A.8.9 to concrete items your team recognises:

Baselines, owners and recurring activities, so engineers see exactly how their tickets and scripts support configuration control, and managers can see who is responsible for reviews and approvals
Specific risks, such as misconfigured internet‑facing services, over‑privileged accounts or weak backup coverage, so configuration work is visibly tied to reduced incidents and stronger customer assurance

You create a single, controlled source of truth

Instead of scattering configuration expectations across emails, private notes and different documentation tools, you can:

Store baseline definitions, overlays, approvals and exceptions in one controlled space with versioning and access control
Use review schedules, To‑dos and reminders so baselines and exceptions are revisited on time, not just when a problem surfaces or an audit appears

You make assurance part of your service, not an afterthought

Because evidence can be attached directly to baselines and controls, it becomes natural to:

Tag RMM reports, cloud policy exports and change records against A.8.9 so you always have current, traceable proof that configuration is under control
Produce simple views for leadership and customers that show where configuration is solid, where improvements are in progress and where you have consciously accepted or are treating specific risks

Presented this way, configuration management becomes a visible strength of your MSP offering. Prospective customers hear a provider who can explain, in straightforward terms, how it keeps environments safe and supportable at scale. Existing clients gain confidence that you are not just reacting to tickets, but running a controlled, improving service that aligns with ISO 27001:2022 and supports their own assurance needs.

If that is how you want your MSP to be perceived, building or extending your information security management system in ISMS.online is a practical, high‑leverage step. It lets you take configuration discipline you already value and turn it into something you can demonstrate consistently in every audit, assessment and renewal conversation.

A.8.9 Configuration Management – MSP Configuration Baselines & Drift Control