Why “Everyone Is Domain Admin” Is Now an Existential Risk for MSPs
An “everyone is domain admin” approach means a single compromised MSP identity can give attackers high‑level control across many customers at once. That single point of failure now conflicts with customer, insurer and regulator expectations that you can demonstrate strict, auditable control over privileged access, not just rely on trust and good intentions. Data protection regulators, for example, increasingly link appropriate access control and clear accountability to what they consider “appropriate security” for service providers, and expect you to be able to show how that control actually works in practice (regulator security guidance).
Treating most technicians as domain admins across many customers turns your MSP into a single point of catastrophic failure. One compromised identity or remote tool can give an attacker rapid access to dozens of client environments, turning a minor incident into a multi‑customer crisis and inviting contract disputes, regulatory scrutiny and difficult conversations with cyber‑insurers.
Strong access control turns a sprawling MSP estate into a manageable level of risk.
The real business risk behind domain admin sprawl
The real risk behind domain admin sprawl is that one compromised account can trigger a multi‑customer security and business crisis. When broad rights are attached to a single identity, even a simple phishing email can escalate into widespread outages, ransom demands and questions about whether you met your contractual obligations.
Over‑privileged technician accounts create a single technical and commercial weak point across your whole customer base. When one account holds broad rights in many tenants, domains, remote monitoring tools and cloud consoles, compromise of that identity lets an attacker behave like a trusted engineer everywhere you operate.
A majority of organisations in the 2025 ISMS.online survey reported being affected by at least one third‑party or vendor security incident in the past year.
In a plausible scenario, a single engineer’s compromised session could be used to push ransomware across dozens of customers in a very short period, forcing you to juggle recovery efforts, notifications and reputational damage all at once. Documented supply‑chain incidents involving MSP tools show how quickly attackers can repurpose legitimate remote administration capabilities in this way, even if the exact timing varies between cases (remote admin tool breach analysis).
Why modern attacks make MSP admin models so dangerous
Modern attacks make legacy MSP admin models dangerous because they are designed to exploit a single point of high privilege and repeat the same techniques across many environments. Once an attacker can impersonate a trusted engineer, they no longer need slow lateral movement; they can use built‑in tools and legitimate channels to achieve rapid impact.
Modern attackers are adept at turning one high‑privilege foothold into broad control. Once they obtain domain‑level access, they can abuse high‑value groups, replication features and authentication mechanisms to forge tickets, add hidden backdoor accounts or push malicious configuration changes. They do not need months of stealthy exploration to cause meaningful damage when your own tools happily execute their instructions.
For MSPs, the danger is magnified because those techniques are applied against a shared remote access model. If one technician account has powerful rights in many client domains, an attacker can repeat the same playbook across each environment with minimal extra effort. That blend of concentrated privilege and centralised tooling explains why MSPs have become prime supply‑chain targets: compromise the provider and you inherit the keys to everyone downstream. Public incident write‑ups have described attackers doing exactly this by abusing MSP remote administration platforms to deploy ransomware and other malware rapidly across multiple customers (MSP supply‑chain intrusion reports).
How customers and regulators now view your admin model
Customers and regulators increasingly see your admin model as a direct indicator of how seriously you treat their risk. They expect you to use least privilege, keep clear records of privileged activity and be able to explain, in plain language, who can do what in their environment and why.
Customers, regulators and insurers now judge MSPs by how they manage third‑party privileged access. They expect you to restrict rights to the minimum necessary, monitor their use carefully and provide detailed evidence on demand. That shift is visible in longer due‑diligence questionnaires, tougher contract language and more probing renewal discussions that go into the details of your admin model, not just your marketing claims. Industry commentary on supplier security also highlights that customers are asking more questions about access control, logging and supplier oversight as part of routine vendor risk assessments (supplier security expectations).
Around four in ten organisations in the 2025 ISMS.online survey said that managing third‑party risk and tracking supplier compliance is a top security challenge.
If you rely on trusted shared admin accounts, inconsistent logging or different practices per customer, those conversations quickly become uncomfortable. You may be excluded from sensitive opportunities, pushed into unfavourable terms or asked to remediate urgently after audits. An everyone is domain admin culture, once seen as a sign of agility, is now widely read as a red flag that you have not fully understood or controlled your role in your customers risk.
Book a demoFrom Convenience to Governance: Reframing Admin Rights Under ISO 27001
ISO 27001 gives you a structured way to replace convenience‑driven admin habits with a defensible access model. The standard does not name domain admins directly, but its focus on risk management and access control aligns closely with least privilege and auditable privileged access. Practical guidance on ISO 27001’s access control requirements, particularly Annex A.9, emphasises using the standard to move from ad‑hoc access arrangements to a risk‑based, policy‑driven model that you can explain and defend to stakeholders (ISO 27001 access control guidance).
Under ISO 27001, you define an information security management system that covers risk assessment, treatment decisions, policies and control implementation, all backed by evidence. Privileged access sits squarely inside that system. Your task is to show that powerful rights for technicians and tools are justified by risk, formally approved, limited, monitored and periodically reviewed, not granted by habit or inherited from earlier phases of growth.
Two‑thirds of organisations in the 2025 ISMS.online State of Information Security survey said the speed and volume of regulatory change are making compliance harder to sustain.
What ISO 27001 actually expects about access and privilege
ISO 27001 expects you to treat access, and especially privileged access, as a managed risk rather than a convenience. You must define access control policies, assign responsibilities, control provisioning and show that rights reflect genuine business need, all supported by records that demonstrate how these controls operate in practice.
The standard requires you to identify information security risks, decide how to treat them and select controls to manage them. Annex A then provides a catalogue of controls covering organisational, people, physical and technological safeguards. Several of those controls clearly focus on how you grant, adjust and revoke access rights, particularly for privileged accounts and critical systems that underpin your MSP services. Implementation guides for ISO 27001 risk assessment describe this as a cycle of identifying risks, evaluating treatment options and selecting appropriate controls that keep risk within agreed tolerances (ISO 27001 risk assessment practice).
In practice, ISO 27001 expects you to maintain an access control policy, define roles and responsibilities, govern user provisioning and document how privileged access is limited and monitored. It also expects you to keep records showing that these controls operate in reality, not just on paper. It is not enough to state that technicians should avoid domain admin unless necessary; you need to show how you enforce that rule and how you check whether it is working consistently across customers and platforms.
Why multi‑tenant MSPs need an explicit governance lens
A multi‑tenant MSP cannot rely on access models designed for single‑organisation environments. Your technicians and tools cross many customer boundaries, which means your governance view must include cross‑tenant admin accounts, remote access platforms and integrations that join your systems to client estates.
Much day‑to‑day ISO 27001 guidance is written with a single organisation managing its own systems in mind. A multi‑tenant MSP works differently. Your technicians and tools cross many customer boundaries, your remote monitoring platform touches multiple networks and your internal systems are often tightly integrated with client infrastructure. All of that still sits within the scope of your ISMS if it supports the services you deliver. Cloud and MSP security guidance from bodies such as ENISA also highlights that shared platforms and cross‑tenant access introduce additional governance and segregation challenges, even when you base your management system on ISO 27001 (cloud security for SMEs).
That means your risk assessment must explicitly cover cross‑tenant admin accounts, remote access tools, service accounts and integrations that bridge environments. Your access control policies must explain not only who can access your own systems, but also how and when your people and tools can act inside client estates. Your Statement of Applicability-the list of Annex A controls you apply and why-should spell out which controls you use for privileged access, and how they operate in both your environment and your customers’ environments.
A dedicated ISMS platform such as ISMS.online can help by linking risks, Annex A controls, access policies and evidence, so your governance view stays aligned with day‑to‑day reality and you are not reliant on scattered documents when auditors or customers ask difficult questions. Public descriptions of integrated ISMS platforms emphasise this centralisation of risk registers, control mappings, policies and evidence to simplify ISO 27001 implementation and oversight (what an ISMS platform provides).
Turning standards language into decisions your board understands
Translating ISO 27001 into business questions makes it easier for your board to understand and challenge your admin model. Instead of discussing clauses and control numbers, you can focus on who can perform which actions, in which environments, under which approvals and for how long.
ISO terminology can feel abstract, especially for non‑specialists. Terms like “Annex A”, “control objectives” and “management review” do not always resonate with MSP leadership. The most effective way to bridge that gap is to translate access control requirements into concrete questions: who can perform which actions, in which environments, using which tools, under which approvals and for how long.
When you answer those questions in business language, the standard becomes less intimidating. Questions such as “who can reset a client’s admin password out of hours?” or “who can change firewall rules across multiple customers?” become specific, testable decisions. ISO 27001 provides the framework; your job is to express it in terms your board, auditors and customers can recognise, challenge and ultimately support with investment.
ISO 27001 made easy
An 81% Headstart from day one
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.
What a Practical Least‑Privilege Operating Model Looks Like for MSPs
A practical least‑privilege model for an MSP lets technicians complete legitimate work quickly while making it hard for anyone to exceed what their role genuinely requires. Everyday tasks run under scoped roles, elevation is temporary and auditable, and non‑human accounts carry only the rights they need.
Thinking in terms of an operating model stops you applying isolated fixes. Instead of tweaking one group or tool at a time, you define how human identities, service accounts, roles, devices, workflows and monitoring fit together. Once that picture is clear, individual control choices become implementation details rather than disconnected experiments, and you can map them cleanly to ISO 27001 controls and Annex A expectations.
Defining roles so technicians are powerful only where they need to be
Role design ensures technicians are powerful only where their work genuinely demands it. You define a small number of role types, decide which actions each role can take and then assign people to roles rather than handing out one‑off admin rights.
Role design is the foundation of a least‑privilege model for MSPs. You already use labels like service desk analyst, project engineer, cloud specialist, security engineer and escalation lead. The key question is which rights each role truly needs, not which rights people happen to have today. For example, a service desk analyst may need to reset passwords and unlock accounts but should not deploy tenant‑wide scripts or change directory configuration.
By aligning permissions to well‑defined roles, you move away from ad‑hoc individual grants and “just in case” domain admin. You assign people to roles and roles to resources. That makes access reviews simpler, reduces privilege creep and gives you a storey that maps directly onto ISO 27001 expectations that rights reflect job responsibilities and business need, rather than personal convenience or history.
Separating human identities from automation and tools
Separating human identities from automation ensures that scripts, agents and tools are treated as distinct security subjects with their own scopes and controls. Each service account should have a clear purpose, limited permissions and secure credential handling that you can explain to auditors without embarrassment.
Many MSPs quietly run automation scripts, backup agents and remote management tools with domain‑level power because it was the quickest way to get them working. Least privilege requires you to treat these non‑human identities with the same care as human admins. Each service account or agent should have a clearly defined purpose, a documented scope and credentials stored and rotated securely.
When you scrutinise these accounts, you often discover they hold more rights than they use. A backup service may only need read and write rights to specific repositories, not full control over the domain. A monitoring script may require local admin on certain servers, not enterprise‑wide privileges. Tightening those scopes reduces your attack surface without changing how technicians work day to day or how customers experience your service.
Using trusted entry points for elevated work
Using trusted entry points for elevated work means high‑risk actions always pass through a small number of hardened, closely monitored systems. That makes it easier to enforce consistent controls and explain your approach when customers or auditors ask how you protect their environments.
Trusted entry points define where and how privileged work is allowed to happen. Rather than connecting from any device and any network, you can require technicians to use hardened admin workstations or jump hosts when performing high‑risk actions. Those systems are locked down, monitored more closely and configured to block everyday web browsing, email and other risky activity.
This approach helps both your security team and auditors because all domain‑level changes pass through a small number of controlled gateways. You can focus logging, monitoring and controls on those points, enforce multi‑factor authentication consistently and ensure privileged sessions are clearly separated from normal user activity. That supports both rapid diagnosis and clear evidence when questions arise about what happened.
Comparing the old and new operating models
Comparing the old and new operating models side by side helps you explain why least privilege is worth the effort. It shows how daily work changes, where risk drops and how your audit narrative becomes simpler and more credible.
The following table contrasts a typical “everyone is domain admin” model with an ISO 27001‑aligned least‑privilege model for MSPs.
| Dimension | Old “everyone is domain admin” model | ISO 27001‑aligned least‑privilege model |
|---|---|---|
| Technician access | Standing domain admin in many tenants | Scoped roles per tenant, elevation only as needed |
| Service accounts | Broad, rarely reviewed privileges | Narrow, documented scopes, regular review |
| Remote support | Unrestricted sessions from any device | Scoped sessions from hardened admin entry points |
| Logging and evidence | Inconsistent, tool‑specific | Central view of privileged activity and approvals |
| Audit narrative | Hard to justify rights or exceptions | Clear mapping from role to right to evidence |
Once you understand these differences, later design work on RBAC, just‑in‑time elevation and privileged access management becomes much easier to frame and justify to both engineers and leadership.
Designing RBAC, Just‑In‑Time Elevation and PAM for Multi‑Tenant MSPs
Role‑based access control, just‑in‑time elevation and privileged access management give you the technical backbone for least privilege across many customers. Together they keep roles consistent, make elevation short‑lived and controlled, and ensure privileged sessions are closely monitored and auditable across on‑premises, cloud and remote management platforms, not just inside a single domain.
The challenge is to make these mechanisms feel like a natural part of your technicians’ workflow rather than an external burden. If elevation flows are clumsy, tickets will be delayed and staff will look for shortcuts. If roles are too narrow or too broad, you will either frustrate engineers or dilute security. Deliberate design helps you find a balance that supports both service quality and risk reduction.
Building a tiered and repeatable role structure
A tiered, repeatable role structure lets you apply consistent access levels across customers and technologies. You define a small number of access tiers, map common tasks to those tiers and then implement them in each platform so technicians see a familiar pattern wherever they work.
A tiered role structure lets you apply consistent access levels across different technologies and customers. At the lowest tier you place workstation and end‑user changes, above that server changes and at the top domain or tenant‑level configuration. Cloud platforms and key applications can be mapped into similar levels so your model spans on‑premises and cloud estates in a way that technicians can easily understand.
In practice, this might mean a helpdesk role that can reset passwords and manage user objects, an infrastructure role that can manage servers and core services, and a small number of specialised roles that can change directory or tenant configuration. Each role is implemented directly in Active Directory, cloud identity providers and key tools, not just described in a document. That gives you a consistent foundation to build on when you introduce elevation, monitoring and ISO 27001 control mappings.
Introducing just‑in‑time elevation instead of standing admin
Introducing just‑in‑time elevation swaps standing admin membership for short‑lived, task‑based privilege. Technicians work under normal roles and request additional rights only when they genuinely need them, with clear time limits and logs that link each elevation back to a ticket or change.
Just‑in‑time elevation replaces always‑on membership of powerful groups with temporary access granted for specific tasks. An engineer working under a standard role requests elevation for a defined period to complete a change or fix, and the system automatically removes the elevated right when the window closes. Requests and approvals are linked to tickets, and the elevated sessions are logged for review and for later audit.
You do not have to deploy a full privileged access management suite on day one to benefit from this approach. Some identity providers, remote access tools and ticketing systems can support basic time‑bound group membership or delegated elevation. Over time, you can evolve towards more advanced models with credential vaulting, session recording and stronger policy enforcement. The key is that technicians no longer need domain admin attached permanently to their accounts for routine work.
Enforcing separation of duties across tenants
Enforcing separation of duties across tenants ensures no single engineer can make unreviewed, high‑impact changes in many environments at once. For particularly sensitive operations you can require two people, with one preparing the change and another approving or executing it, and keep clear records of that split.
Separation of duties is not just about stopping one person from initiating and approving the same high‑risk change. In a multi‑tenant MSP, you must also consider the risk that one engineer can make unreviewed changes across many customers. For particularly sensitive operations, you may decide that two people should be involved: one to prepare the change and one to approve or execute it.
You can build that separation into workflows around firewall changes, identity provider configuration, backup policy updates and other cross‑tenant activities. Approvals can be handled in your service management tool, referenced in your ISMS and backed by logs from your technical platforms. This reassures customers and auditors that no single account has unchecked power over multiple environments and that ISO 27001 separation‑of‑duties expectations are met in practice rather than in name only.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
Step‑by‑Step Migration Away from Default Domain Admin
You can move away from default domain admin through a phased programme that starts with visibility and progresses through pilots, refinement and wider rollout. You do not need to remove domain admin rights everywhere at once to align with ISO 27001 and least‑privilege principles; a phased approach lets you reduce risk quickly where it is highest, learn what works in your environment and avoid breaking critical services, especially when you treat the work as part of your wider information security programme rather than a side project for one enthusiastic engineer.
A clear migration plan usually starts with visibility, then moves through role design, elevation mechanics, pilots and wider rollout. Throughout the process, documenting decisions, updating policies and collecting evidence are as important as the technical changes. That documentation feeds your risk register, Statement of Applicability and management review, and becomes the backbone of your audit and customer storey.
Gaining honest visibility into privileged access
Honest visibility into privileged access begins with a complete inventory of powerful accounts, tools and service identities across your own environment and all customers. Without that map, you cannot prioritise changes or show auditors that you understand where high risk really sits.
Visibility into your real privileged landscape is the first step in any credible programme. You need an inventory of how many domain admin and equivalent accounts you have across your own systems and all customers. That includes technician accounts, shared admin logins, service accounts and tool integrations, as well as cases where remote access tools quietly allow implicit or hidden elevation. ISO 27001 implementation guidance on risk assessment often treats this kind of inventory as a core input into formal risk analysis and the selection of appropriate controls (ISO 27001 risk planning).
Once you have that inventory, you can assess relative risk. Accounts used rarely but holding broad rights, shared credentials that are hard to attribute and identities used by many automations are often high‑priority. From an ISO 27001 perspective, this work feeds directly into risk assessment and risk treatment. These are the situations where you must decide which controls, including least‑privilege mechanisms, you will apply.
Designing phases, pilots and safe rollbacks
Designing phases, pilots and safe rollbacks helps you change access models without undermining service quality. You start small, learn from early results and maintain clear ways to restore previous access if an unexpected issue arises.
Trying to change everything at once is risky and difficult to manage. It is safer to run small, well‑defined pilots where you remove standing domain admin rights for a subset of technicians or customers, replace them with scoped roles and basic just‑in‑time elevation and measure the impact. Success measures might include resolution times, number of elevation requests and operational incidents.
Equally important is to define clear rollback options. If a particular change unexpectedly affects a customer system, you must be able to restore previous access quickly while you investigate. Documenting these rollback plans reassures technicians and leadership that the programme is being handled carefully, not recklessly. Those plans, pilots and outcomes provide valuable evidence for management review and for demonstrating continual improvement.
Turning changes into auditable artefacts
Turning changes into auditable artefacts means updating policies, procedures and Statements of Applicability as you adjust roles and elevation flows, and capturing evidence that these controls operate consistently across customer environments.
As you adjust roles, remove rights and introduce elevation flows, your policies, procedures and Statement of Applicability should evolve in parallel. Access control policies should be updated to describe the new model in plain language. Operational procedures must show how technicians request and use elevated access. The Statement of Applicability should reference the Annex A controls you rely on for privileged access and explain how they operate across your own and your customers’ environments.
You should also start collecting evidence that these controls operate consistently: records of access reviews, logs of elevation events, samples of approvals and examples of configuration changes. Storing this evidence in a structured way makes ISO 27001 audits and customer due‑diligence much easier. An ISMS platform such as ISMS.online can help by linking risks, controls, policies and evidence in one view so you do not have to rely on scattered documents and screenshots.
Step 1 – Map current admin rights
Create a complete inventory of privileged accounts, tools and service identities across your own environment and all customers, including shared and legacy credentials.
Step 2 – Design and test your target model
Define roles, elevation rules and pilots, then test them on a limited set of customers with clear rollback plans and success measures before broader rollout.
Step 3 – Embed changes into policies and evidence
Update access control policies, procedures and your Statement of Applicability to reflect the new model, and start collecting logs, reviews and approvals as ongoing evidence.
Step 4 – Review, learn and refine
Use incidents, feedback and metrics to refine roles, elevation rules and workflows, and bring persistent exceptions into management review as managed risks.
Balancing Rapid Remote Support With Audit‑Ready Controls
Balancing rapid remote support with audit‑ready controls means technicians act quickly under scoped roles and every privileged action leaves a clear trail. Done well, controls become part of normal work rather than a visible barrier and support both service quality and assurance.
MSPs live and die by how quickly they can restore services and solve customer problems, so any change to access models must respect that reality. Least privilege and just‑in‑time elevation can be designed to support, rather than hinder, rapid remote support. The key is to embed controls into tools and workflows your technicians already use, instead of asking them to juggle separate manual steps.
At the same time, those workflows must leave behind a trail that satisfies auditors and customers: who accessed what, when, under which approvals and what they did. That audit trail is not an optional extra. ISO 27001 treats it as central to proving that your access controls are effective in real operations, not just in policy documents.
Redesigning remote support flows for scoped access
Redesigning remote support flows for scoped access means aligning identity, roles and remote tools so technicians get the access they need for a given ticket and nothing more. Individual accounts, strong authentication and role‑based controls should work together to make broad domain admin unnecessary in most cases.
Redesigning remote support flows means aligning identity, role and tool configuration so engineers get the access they need without carrying domain admin everywhere. Technicians should sign in to remote monitoring and management platforms, remote desktop tools and cloud consoles with individual accounts protected by multi‑factor authentication. Those accounts should be assigned to roles that define what they can do for which customers.
For example, a first‑line support role might allow technicians to remote into user workstations, reset passwords and perform specific troubleshooting tasks but not make deep system changes. Elevated roles would be restricted to fewer people and used only under controlled circumstances. A service desk lead can then see that response times remain strong while segregation improves, so both operations and audit concerns are addressed.
Binding elevation to tickets and changes
Binding elevation to tickets and changes ties privileged access directly to documented work. Each elevation request is connected to a specific incident, change or task, and time‑bound, so you can later show why extra rights were granted and how long they lasted.
Binding elevation to service management processes is a powerful way to keep speed and control in balance. When a technician needs temporary higher rights, they raise or update a ticket that describes the work and requests elevation. That request can be auto‑approved for low‑risk tasks or require explicit approval for higher‑risk actions. Once granted, the elevated right is time‑bound and removed automatically when the window closes.
Because each elevation is linked to a specific ticket or change, you can later show how that access related to a documented request. Auditors and customers increasingly want that level of justification for privileged actions. For technicians, if designed sensibly, this becomes one more click in the workflow they already follow when handling tickets, not an extra system to manage.
Demonstrating that performance has not suffered
Demonstrating that performance has not suffered requires you to measure response and resolution times before and after changes, and to discuss any differences with teams in a transparent way. If performance holds steady or improves, you have strong evidence that least privilege is compatible with good service.
Concerns that extra controls will slow down response and resolution times are understandable. The best way to address them is to measure before and after. Before you change the model, capture baseline performance metrics such as mean time to respond, mean time to resolve, frequency of out‑of‑hours escalations and number of incidents requiring privileged access. Then track the same metrics after your pilots and wider rollout.
If you see no meaningful degradation-or even improvements due to fewer self‑inflicted incidents-you have a strong storey for both internal stakeholders and external auditors. If metrics do show friction, you can adjust roles, elevation rules or approval thresholds using hard data rather than reverting to broad domain admin. Those measurements also give you useful input for performance evaluation and continual improvement in your ISMS.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Pitfalls, Edge Cases and Metrics in MSP Least‑Privilege Programmes
Least‑privilege programmes fail when exceptions, workarounds and weak metrics quietly undermine your design. To keep control, you must treat stubborn edge cases as managed risks, watch for human shortcuts and track indicators that show whether privilege is genuinely reducing or just being renamed.
Even a well‑designed least‑privilege programme can falter if you ignore common pitfalls and awkward edge cases. MSPs often underestimate how many scripts, integrations and legacy systems depend on broad rights, or how quickly technicians will find workarounds if processes feel slow or arbitrary. Anticipating these issues and watching the right metrics helps you keep your programme honest and effective over time.
In the 2025 ISMS.online survey, only about 29% of organisations reported receiving no fines for data‑protection failures, while the majority had been fined, including some with penalties above £250,000.
ISO 27001 expects continual improvement and regular evaluation of control effectiveness, not a one‑off redesign. That means you must be willing to test your assumptions, learn from incidents, adjust your model as your customer base changes and bring persistent exceptions into management review, rather than leaving them as hidden compromises outside your ISMS. The standard’s clauses on performance evaluation, management review and continual improvement are built around this expectation of ongoing testing and refinement (ISO 27001 continual improvement guidance).
Recognising and managing unavoidable exceptions
Recognising and managing unavoidable exceptions means acknowledging that some systems still need high privilege, recording why, adding compensating controls and reviewing the situation regularly instead of pretending those risks do not exist.
Some systems genuinely require high privileges to function, at least in the short term. Legacy applications, line‑of‑business systems without granular roles and certain backup or monitoring mechanisms may not support fine‑grained access. In those cases, pretending that least privilege is fully enforced is unhelpful. Instead, you should treat them as documented, risk‑managed exceptions.
For each exception, record why high privilege is required, which compensating controls are in place and how you plan to address the dependency over time. Link these entries to your risk register and reference them in your Statement of Applicability. Review them regularly in management review meetings. Auditors are usually more comfortable with transparent, actively managed exceptions than with silent workarounds that contradict your stated policy.
Watching for human workarounds and control fatigue
Watching for human workarounds and control fatigue helps you spot where your design clashes with real‑world work. If processes are slow, confusing or arbitrary, technicians will bypass them, and your least‑privilege model will exist only on paper.
Human workarounds can quietly undo months of careful design. If privilege elevation feels slow, confusing or arbitrary, technicians will look for ways around it. They might keep local copies of credentials, use unsanctioned tools or perform actions under someone else’s account. These behaviours defeat the purpose of your design and are often harder to detect than the original risks.
Keeping communication open with engineering and support teams is essential. Regular feedback sessions, anonymous surveys and careful analysis of logs can reveal where friction is highest. Training should explain not just how to use new tools and processes, but why they exist and which specific risks they address. Wherever possible, refine workflows to remove unnecessary friction without weakening checks and balances, so technicians see controls as part of professional practice rather than arbitrary obstacles.
Choosing metrics that show real progress
Choosing metrics that show real progress means tracking numbers that reflect both security improvement and operational reality. You want to see privileged rights shrink, just‑in‑time use grow and evidence become easier to produce, without unacceptable impact on service.
Good metrics help you see whether your least‑privilege programme is genuinely reducing risk or just generating paperwork. You need indicators that reflect both security and operations, and that are easy to explain to leadership and auditors.
Useful metrics often include:
- Number of accounts with standing domain‑level rights.
- Proportion of privileged actions performed under just‑in‑time elevation.
- Coverage of logging and monitoring for elevated sessions.
- Number and severity of audit findings related to access control.
You might also track how long it takes to produce evidence for a sample of privileged actions, such as who approved a change or who accessed a particular system. A decreasing effort trend suggests your documentation and tooling are improving. Presenting these metrics in management review meetings shows that least privilege is being treated as a strategic, evolving programme rather than a static configuration change.
Why ISMS.online Is a Strong Fit for Your Least‑Privilege ISO 27001 Journey
ISMS.online helps you turn the move from domain admin sprawl to least privilege into a structured, audit‑ready ISO 27001 programme that your customers, auditors and leadership can understand and trust. Instead of juggling scattered spreadsheets and screenshots, you gain a single place for your risk register, Annex A mappings, access policies and control evidence, all aligned with your least‑privilege operating model. Descriptions of integrated ISMS platforms highlight this kind of centralisation as a practical way to keep risk, control design and evidence in step as your environment evolves.
In the 2025 ISMS.online survey, almost all organisations listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a priority.
What you can explore in an ISMS.online session
In a short session, you can explore how to link privileged access risks to Annex A controls, policies and evidence in a way that reflects multi‑tenant MSP reality. You see how Statements of Applicability, management reviews and access control procedures come together to tell a clear storey about how you manage powerful rights across client environments and how those decisions tie back to your risk assessment.
For your security and compliance lead, ISMS.online provides a central view of which Annex A controls apply to privileged access and how they are implemented, along with links to risk assessments, Statements of Applicability and records of reviews. For your lead engineer and operations teams, you can attach role definitions, elevation workflows and sample logs to the same controls, so governance reflects the way work actually happens and not an idealised design on a slide.
How a guided session supports your first 90 days
A guided ISMS.online session can also help you sketch a realistic first 90‑day plan for an ISO 27001‑aligned least‑privilege programme. You can map how visibility, role design, elevation pilots and evidence collection fit into existing projects and how to present that plan to leadership and key customers in language they recognise.
For your managing director, this translates into a clearer narrative about how your MSP protects client environments, meets contractual and regulatory obligations and differentiates on security. You can track progress over time through metrics and evidence, for example as domain admin usage shrinks, just‑in‑time elevation is adopted more widely and privileged sessions are more consistently logged and reviewed, rather than assuming those changes will happen automatically. Choose ISMS.online when you want to turn that least‑privilege journey into an audit‑ready ISO 27001 programme that strengthens customer trust and simplifies the storey you tell to regulators, insurers and your own board.
Book a demoFrequently Asked Questions
How should an MSP explain “least privilege” to customers and auditors who are used to hearing “all our engineers are domain admin”?
Least privilege means your engineers still fix things quickly, but each person only has the access they genuinely need, for the shortest possible time, and you can prove that to any customer or auditor.
How can you turn “least privilege” into a simple, checkable storey?
Non‑technical people don’t want a lecture on Active Directory; they want a model they can picture and verify. A clear way to describe it is as three layers of control:
- Everyday roles at the base: – service desk, project engineers, cloud specialists and security staff each use named accounts with defined rights in on‑prem and cloud environments. Password resets, user onboarding, routine server work and everyday tenant configuration are all handled here, without blanket domain admin.
- Temporary elevation in the middle: – when an engineer needs extra power for a specific job, they request time‑limited elevation tied to a ticket or change. Someone appropriate approves it, the extra rights appear for a short window, and then they disappear automatically.
- A small emergency “break‑glass” layer at the top: – a tiny number of highly controlled options for genuine emergencies, with strict rules, dual control where possible and immediate post‑incident review.
This lets you say things customers and ISO 27001 auditors can check:
- “Password resets always use this role, never domain admin.”
- “Tenant‑wide changes always require this level of approval.”
- “Here’s how we log, review and improve all of it.”
That moves you from “trust us” to observable control.
How do you make that explanation stand up under audit?
An explanation becomes credible when it matches what you can show on screen and on paper:
- You have a role catalogue that reflects how your engineers actually work, not just job titles.
- You can produce examples of elevation events linked to tickets, showing who requested, who approved and when access ended.
- You can demonstrate that powerful work happens via hardened admin workstations or jump hosts, not from any unmanaged laptop.
ISMS.online helps you tie this storey into your Information Security Management System (ISMS). You can connect roles, elevation rules, admin workstation use and exception handling directly to risks, Annex A controls and real evidence. When you walk an auditor through one concrete example – from risk → control → role → log → review – they see that “least privilege” is not just a slogan, it is the way you run your MSP.
How can an MSP reduce standing domain admin rights without outages or support bottlenecks?
You reduce standing domain admin rights safely by treating it as an engineering change programme: understand where privilege actually lives, design a realistic target model, run controlled pilots, then roll out with clear rollback options and good communication.
What is a safe, engineer‑friendly sequence for removing standing domain admin?
A practical approach usually follows four stages:
- Discover real privilege and dependencies
Build an honest picture of where powerful access exists across a representative set of tenants and your own environment:
- Domain and enterprise admin groups and any nested groups.
- Shared “god” accounts and local administrator passwords.
- Service accounts, scheduled tasks and backup jobs that rely on high privilege.
- Remote monitoring and management (RMM) tools and other paths that can reach domain controllers.
This shows the true blast radius of a compromised account and stops you unintentionally breaking automation or maintenance tasks that silently depend on domain admin.
- Design roles and elevation around real work
Map access to tasks and tools, not just job titles:
- Which activities belong in baseline support roles (for example, user management, most server administration)?
- Which genuinely need extra privilege (for example, schema changes, forest‑level actions)?
- What approvals, time limits and logging are appropriate for each category?
You end up with scoped roles (directory admins, server admins, cloud admins and so on) and clear rules for when temporary elevation is allowed.
- Pilot on safe ground before touching critical tenants
Start with your own internal systems or low‑risk customers:
- Remove standing domain admin from a small group of engineers.
- Assign them to the new scoped roles.
- Introduce just‑in‑time elevation for rare tasks that still need broader rights.
- Track incident rates, resolution times and customer feedback closely.
When something breaks, use it as a design signal: fix the role, the script or the workflow rather than quietly putting people back into domain admin.
- Roll out through change management with clear rollback paths
Once pilots are stable:
- Schedule changes through your change‑management process, with clear communication to engineers and customers.
- Plan maintenance windows where necessary.
- Define and approve rollback options in advance.
- Log any exceptions explicitly, with owners and review dates, instead of letting “temporary” privileges become permanent again.
Capturing the risks, design decisions, change records, pilot results and Statement of Applicability updates in ISMS.online gives you a traceable improvement storey. When customers or ISO 27001 auditors ask what you did about over‑privileged access, you can step through each stage calmly and show that you engineered the change rather than gambling with production estates.
How do ISO 27001:2022 clauses and controls support an MSP’s least‑privilege model in client environments?
ISO 27001:2022 gives you both the management expectations and the detailed controls you need to justify and maintain least privilege across your own and your customers’ systems.
Which ISO 27001:2022 clauses matter most for MSP least privilege?
Several core clauses set the tone for how you approach privileged access:
- Clause 4 – Context of the organisation:
You are expected to consider the fact that you hold administrator‑level access into many customers as part of your context and stakeholder expectations.
- Clause 6.1 – Actions to address risks and opportunities:
Risks like “MSP engineer misuse of remote access” or “shared domain admin credentials across tenants” should appear in your risk register with clear treatment plans.
- Clause 8 – Operation:
How your engineers authenticate, elevate, use RMM tools and handle “break‑glass” situations must follow defined, controlled procedures, not personal preference.
- Clause 9 – Performance evaluation and management review:
You should measure whether your least‑privilege design is working (for example, number of domain admins, elevation frequency, exception counts) and discuss those figures in management review.
These clauses turn least privilege into an ongoing management responsibility, not a one‑time technical clean‑up.
Annex A then provides the levers MSPs use to implement least privilege:
- Access control and identity management:
Controls require you to:
- Base access on roles and responsibilities, including for external and MSP staff.
- Keep privileges to the minimum necessary and review them regularly.
- Manage user lifecycle cleanly across all tenants when staff join, change roles or leave.
- Use of privileged utilities and tools:
You are expected to define who can use powerful tools such as RMM platforms, backup consoles and directory utilities, from where they can be used, and under what monitoring.
- Separation of duties and high‑risk changes:
For actions that could affect multiple tenants – for example, pushing group policy changes across many customers – there should be extra checks or dual approval.
- Logging and monitoring:
Privileged actions must be logged, protected and reviewed so that misuse or error can be detected and followed up.
In ISMS.online you can show this connection clearly:
- The risk register documents the exposure created by engineers with broad access.
- The Statement of Applicability records which Annex A controls you selected and why.
- Policies and procedures: describe your role model, elevation path, admin workstation use and emergency access.
- Evidence records: hold access‑review outputs, elevation samples, tool configurations and internal audit findings.
That level of end‑to‑end traceability gives ISO 27001 auditors and customers confidence that your least‑privilege approach is not just well‑intentioned, but actively designed, monitored and improved.
How can an MSP keep remote support fast while enforcing least privilege and satisfying ISO 27001 auditors?
You keep remote support fast by building least‑privilege patterns into the tools engineers already use, so most tickets are resolved under standard roles, and the minority that need more power follow quick elevation routes that automatically create the audit trail ISO 27001 expects.
How do you design roles and elevation so speed and control work together?
Start with named identities and role‑based access across your core platforms – RMM, remote access, ticketing, cloud consoles and key SaaS services:
- Map common tasks like user administration, password resets, workstation troubleshooting and most server work to roles that do not require full domain admin.
- Reserve broad rights for a smaller set of well‑defined activities such as complex migrations, cross‑tenant policy changes or advanced troubleshooting.
For tasks that genuinely need extra rights:
- Allow engineers to request just‑in‑time elevation from within the ticket or change they are working on.
- Make the request flow simple but structured: reason, scope, expected duration.
- Route approvals according to risk: team‑lead approval for routine but sensitive work; dual sign‑off for estate‑wide changes.
- Ensure rights expire automatically when the window closes.
This approach means:
- Engineers stay inside the tools and queues they already live in.
- Elevation becomes part of the normal ticket flow, not a separate governance system that staff try to bypass.
- You gain detailed evidence: who elevated, why, who approved, what was done and for how long.
If you compare response and resolution metrics before and after introducing this model, you can often show that service quality is maintained or even improves. Engineers spend less time juggling multiple accounts or hunting for someone with “magic keys,” and high‑risk work happens in a more orderly way.
When you link these patterns back into ISMS.online – access‑control policies, change records, elevation logs, performance reports and management review outputs – you present ISO 27001 auditors with a coherent operating model. They see that fast support and strong control are two outcomes of the same design, not opposing forces.
What signals show that an MSP’s least‑privilege design looks good on paper but is failing in practice?
A least‑privilege model can look neat in documentation yet fall apart when people are under pressure. The warning signs usually appear in how engineers behave, where privileged work actually happens and how often you quietly undo controls.
What technical and human symptoms suggest your model is drifting?
On the technical side, pay attention to patterns like:
- Automations failing after permissions are tightened: – scheduled tasks, backup jobs or RMM scripts that stop working, followed by quick changes that simply restore broad rights.
- The same engineers repeatedly receiving wide temporary access for similar reasons, without that pattern triggering a redesign of roles or tooling.
- Privileged sessions originating from unmanaged devices or unexpected locations, despite your stated policy on admin workstations or jump hosts.
On the human side, listen for:
- Technicians describing processes as “too slow” or “too awkward,” then quietly finding shortcuts.
- Pushback that “no other MSP does it this way,” which can turn into unsanctioned tools or shared passwords if it is not addressed constructively.
Treat these as data, not insubordination. A healthy approach is to:
- Run periodic access reviews and simple test exercises aimed at finding ways around your current controls.
- Analyse repeated elevation requests and incidents to identify where new roles, better scripts or clearer guidance would reduce friction.
- Hold structured feedback sessions where engineers can raise legitimate obstacles and see them turned into logged improvement tasks or, where necessary, documented exceptions with compensating controls and review dates.
Keeping exception registers, audit results, engineer feedback and improvement actions in ISMS.online makes drift visible. Management can see where the design and reality diverge, and you can show auditors and customers that you treat friction and failure as part of a continuous improvement cycle, not something you hide until the next incident.
How does ISMS.online help an MSP turn least‑privilege ambitions into a provable ISO 27001‑aligned operating model?
ISMS.online gives you a single place to connect the technical design of least privilege with the governance, evidence and improvement loop that ISO 27001 expects, so you can show customers and auditors a living system rather than a collection of slideware.
How can you build and run a least‑privilege programme inside your ISMS?
A typical path looks like this:
-
Describe the real risks
Use the risk register to capture scenarios such as “shared admin accounts across multiple tenants” or “RMM agents with overly broad rights.” Assess likelihood and impact realistically and decide what needs attention first. -
Choose and justify your controls
In your Statement of Applicability, select relevant Annex A controls for access control, identity management, logging, separation of duties, supplier management and so on. Record why each control is relevant to your MSP model. -
Document how design meets controls
Policies and procedures in ISMS.online should explain:
- How roles work across different platforms and customer environments.
- How and when temporary elevation is allowed, including approvals and logging.
- Where and how admin workstations or jump hosts are used.
- How emergency access is handled and followed up.
-
Plan and deliver the changes
Use projects and work items to track the work needed to move from current state to target state: cleaning up groups, adjusting RMM configurations, introducing admin workstations, running pilots and expanding rollout. -
Attach real evidence and keep it current
Store concrete artefacts next to the risks and controls they relate to:
- Samples from access reviews and membership exports from privileged groups.
- Logs and reports of elevation activity.
- Screenshots or reports from hardened admin workstations.
- Internal audit findings, management review minutes and agreed actions.
- Show the improvement over time
As you reduce standing privilege and refine your model, update risks, controls, SoA notes and improvement tasks. That gives you a visible trail of how your least‑privilege approach has matured.
For day‑to‑day work, this means your team spends less time chasing scattered evidence and more time refining the actual design. When audits or customer questionnaires land, you can respond with consistent, well‑structured answers backed by the same records your engineers rely on.
If you are early in your journey, using ISMS.online to frame a simple 60–90‑day roadmap – mapping current admin usage, agreeing realistic reduction milestones, assigning owners and dates – turns “we should do least privilege” into a programme you can actually deliver. That kind of visible, managed progress is what convinces boards, auditors and customers that your MSP takes privileged access seriously and is building a model they can rely on for the long term.
