How ISO 27001 A.5.36 Proves MSPs Follow Security Rules With Real Evidence

Why A.5.36 Matters for MSPs Delivering Managed Security Services

A.5.36 matters for managed service providers because it tests whether your security rules are truly followed in live operations, not just written down, and demands evidence that your people and systems follow those rules in day‑to‑day work. It no longer lets you hide behind a policy library; it expects you to prove that policies, standards and rules are understood, applied and corrected when they are not, across both your internal environment and the services you run for customers, spanning many tools, teams and time zones.

The information here is general and does not constitute legal, regulatory or certification advice. For decisions about your organisation, you should consult suitably qualified professionals and your chosen certification body.

At a high level, ISO/IEC 27001:2022 control A.5.36 requires you to do three things:

Define the information‑security policies, rules and standards that apply in your organisation.
Regularly review whether people and operations comply with them.
Act when they do not, and keep evidence that all of this is happening.

For most organisations that is challenging. For an MSP delivering managed security services, it is much tougher. You are not only responsible for your own staff and systems; you are also operating within customer environments, on customer data, under customer policies and sector regulations. Your “rules and standards” quickly include:

Your own information security policy and topic‑specific standards.
Customer security schedules, acceptable‑use clauses and data‑handling requirements.
External standards you commit to, such as configuration baselines or industry codes of practice.

A majority of respondents to the 2025 ISMS.online State of Information Security survey said they had been impacted by at least one third‑party or vendor security incident in the past year.

If you provide services such as a security operations centre (SOC), managed detection and response, vulnerability management or endpoint management, customers increasingly see A.5.36 as their hook for asking: “How do we know you follow your own rules and ours – and what happens if you do not?”

That is one reason boards and investors are now asking tougher questions about MSP governance. Industry research on ISO 27001 and wider cyber risk also notes increased board‑level scrutiny of security and governance, particularly around third‑party providers and outsourcers, reflecting a broader shift in expectations about how risk is overseen. A single misaligned rule in your SOC or remote monitoring and management (RMM) platform can damage multiple customers at once, so they want assurance that your documented controls match operational reality. Independent analysis of cyber‑resilience and the human factor similarly highlights how weaknesses in shared platforms or processes can amplify the impact of individual errors across many organisations, especially where human behaviour and process discipline are critical.

A platform such as ISMS.online can help by giving you one place to define your policies and standards, map them to services, assign responsibilities and link them to real evidence from audits, reviews and operational tools. That does not remove the need to do the work, but it makes the relationship between “what we say” and “what we can prove” visible and manageable.

Compliance earns trust when your evidence shows what really happens, not what you hope happens.

What A.5.36 actually requires in plain language

A.5.36 requires you to keep security rules clear, check that people follow them and fix issues when they do not, and to be able to show auditors and customers that this loop operates in practice through tangible evidence, not just intentions. In practical terms, this means showing that compliance with your information security policy and topic‑specific policies, rules and standards is regularly reviewed and that non‑compliance is dealt with appropriately as part of a living control loop that links rules, behaviour, checks and improvements.

For an MSP, that loop typically looks like this:

Define: You maintain a clear, current set of rules that apply to staff, contractors and, where relevant, customer environments.
Communicate: People know the rules and acknowledge them through training, briefings and onboarding.
Monitor: You use technical monitoring, process checks and internal audits to see whether those rules are being followed.
Respond: When you find non‑compliance, you log it, assess impact and take corrective or disciplinary action where appropriate.
Improve: You review patterns of non‑compliance and adjust policies, training or controls.

Auditors do not expect perfection. They expect a controlled, evidenced cycle. Enterprise customers expect the same, especially where your service is part of their critical infrastructure or regulatory scope. A.5.36 ties directly into ISO 27001’s Plan–Do–Check–Act cycle: you plan the rules, operate controls, check compliance and act on what you learn.

Why the control bites harder for MSPs

A.5.36 bites harder for MSPs because small weaknesses in how you enforce rules can scale across many services and customers. If your internal governance is loose, a single weak standard or exception can quietly undermine several managed security offerings at once.

For many providers, A.5.36 exposes a hidden mismatch: sales and contracts promise one level of control, policies describe another and operations deliver something else entirely. Because your services are multi‑tenant and tool‑driven, weaknesses can propagate quickly:

A lax admin‑account rule in your own environment can weaken every managed security service you provide.
A patching standard that is inconsistently applied across customers can lead to repeated findings in customer audits.
A shared runbook that is not updated when policies change can quietly drift out of compliance.

Around 41% of organisations in the 2025 ISMS.online survey named managing third‑party risk and tracking supplier compliance as one of their biggest information‑security challenges.

Customers and regulators are increasingly aware of this. They use questions aligned to A.5.36 to probe how you govern your staff and subcontractors, how you monitor adherence to rules in multi‑tenant tools and how you handle exceptions. A superficial response - we have a policy and we train staff - no longer satisfies them.

Treating A.5.36 as a core MSP governance control, rather than a narrow documentation requirement, gives you a chance to align promises, policies and practice. When you can show that alignment reliably, it becomes a differentiator in competitive bids, especially for customers that see their MSPs as part of their own regulatory perimeter.

Book a demo

The Pain: Point‑in‑time, Paper‑only Compliance for MSPs

Point‑in‑time, paper‑heavy compliance keeps you passing audits while quietly increasing real risk, cost and stress between assessment dates. Guidance from European cybersecurity bodies on ISO 27001 warns that checklist‑driven or purely audit‑focused approaches tend to leave residual operational risk and strain because they do not reflect how systems and services behave between formal assessments. It concentrates effort into short bursts instead of building routine checks that track compliance throughout the year.

If you are honest about how you currently handle A.5.36, there is a good chance most of the effort happens in short, intense bursts around external audits, customer assessments or major RFPs, rather than as part of everyday operations.

A typical pattern looks like this: several times a year, your security and operations leaders drop everything to assemble evidence packs. They chase exportable reports from ticketing, RMM and security information and event management (SIEM) tools, pull training logs from HR systems and create tailored slide decks for particular customers. Outside those peaks, little systematic checking happens beyond what individual engineers and managers remember to do.

This approach has several costs. It burns time that could be spent improving controls. It depends heavily on a few key individuals. It hides real weaknesses behind snapshots that look acceptable on the day. It also leaves you exposed if a customer or regulator asks for assurance at short notice.

Compliance that only wakes up at audit time usually misses how your services really run.

Where point‑in‑time compliance breaks down

Point‑in‑time evidence will remain part of external audits and due‑diligence exercises, but relying on it as your primary assurance model leaves predictable gaps, and for MSPs three weaknesses show up again and again. Most obviously, point‑in‑time compliance allows rule breaches to go undetected for long periods: incidents and nonconformities often involve known rules that were not being followed because, although the rules existed, there were no regular, risk‑based checks.

Dependence on last‑minute heroics and fragmented evidence is another weakness. Compliance depends on a handful of engineers and managers doing the right thing in addition to their normal workload, without structured prompts or checks. They pull artefacts from scattered tools into hastily assembled packs. When those people leave, fall ill or become overloaded, controls quietly degrade and the storey you tell to customers becomes harder to reconstruct.

If you operate in highly regulated sectors, or serve customers that do, those weaknesses can contribute to lost deals, more severe audit findings or extended remediation plans, especially when they coincide with other shortcomings in control design or oversight. Even in less regulated markets, they increase the chances that a customer will question your professionalism if you struggle to demonstrate how you enforce your own rules.

Recognising these pains is uncomfortable, but it sets the stage for a different way of thinking about A.5.36: not as an occasional hurdle, but as an ongoing discipline that protects customers and your own reputation.

Hidden costs in people, tools and customer trust

Hidden costs of point‑in‑time compliance show up in people, tools and relationships. Teams experience compliance work as unpredictable, last‑minute pressure, which undermines morale and reinforces the perception that rules are an overhead rather than part of good engineering and service practice. Over time, that perception feeds burnout and turnover in key roles.

For example, many mid‑size MSPs report spending significant time – often running into weeks of effort – before a major RFP or customer audit manually pulling logs, screenshots and training records together. The work is stressful, the outputs are hard to reuse and the team emerges with little sense that anything has improved in how services actually run.

There is also a tooling cost. MSPs invest heavily in professional services automation (PSA), RMM, SIEM, identity and logging platforms. If the evidence you provide for A.5.36 lives mainly in spreadsheets and screenshots, you are not getting full assurance value from those tools. You may even be paying twice: once for the tools and again for the manual effort to extract and combine relevant information.

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

Finally, customers notice. Security questionnaires now commonly ask not just “Do you have a policy?” but “How do you monitor compliance with it?” and “What metrics do you track?” Coverage in specialist security and governance publications shows the same pattern, with more procurement and risk teams asking how controls are enforced and measured, rather than stopping at simple yes/no policy questions. If your answers are vague, or you cannot provide examples without weeks of preparation, risk and procurement teams will draw their own conclusions about your maturity.

Moving away from point‑in‑time thinking means accepting that some rules will be imperfectly followed, but insisting that deviations are visible, explainable and used to drive improvement rather than being hidden until the next audit. That shift is what continuous assurance is designed to support.

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

Reframing: From Static Compliance to Continuous Assurance

Reframing A.5.36 as a design problem turns it from an annual checkbox into a manageable part of how you run MSP operations. Instead of asking how to survive the next audit, you ask how to build a reasonable level of ongoing assurance into everyday work.

Continuous assurance does not mean monitoring every rule in real time across every system. It means choosing sensible cadences and mechanisms so that important rules are checked often enough, checks are embedded in normal workflows and tools and evidence is collected as a by‑product of doing the work rather than as a separate reporting exercise.

A strong majority 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.

This mindset aligns well with how ISO 27001 itself is structured. The standard already asks you to plan, operate, monitor and improve your management system. A.5.36 focuses that cycle on whether you are following your own rules and standards, and whether you respond when you are not.

A small comparison makes the shift clearer. Point‑in‑time compliance concentrates effort into a few stressful peaks and leaves long periods with little visibility. Continuous assurance spreads effort out, reduces surprises and makes it easier to spot problems early. The table below summarises the main differences.

Dimension	Point‑in‑time compliance	Continuous assurance
Cadence	Peaks before audits and big questionnaires	Regular, risk‑based checks throughout the year
Effort profile	Manual, stressful bursts	Smaller, predictable activities in normal flows
Risk exposure	Gaps between audits easily go unseen	Deviations surfaced and resolved more quickly
Evidence quality	Reconstructed from scattered sources	Generated as part of routine work and monitoring

The aim is not perfection, but a simple loop that works most of the time and can be explained to auditors, customers and internal stakeholders. When you design that loop carefully, you reduce stress and make policy compliance feel like part of running good services, not an extra project.

What continuous assurance looks like in practice

Continuous assurance links your rules, controls, evidence and decisions so they reinforce one another. Each part of the loop can be adjusted as your services evolve.

A straightforward pattern uses four building blocks:

Inputs: Policies, standards and customer requirements that define how things should be done.
Control activities: Technical controls and procedural steps that embed those rules in daily work.
Evidence artefacts: Logs, tickets, reports and sign‑offs that show what actually happened.
Feedback loops: Governance forums, risk registers and management reviews that use the evidence to make changes.

For example, a rule that “all high‑risk changes must be approved by both a technical owner and a customer representative” might be embodied in your change‑management workflow, enforced by your ticketing system, evidenced by approval records and reviewed periodically in an internal audit or management review.

You do not need to put every rule on a daily monitoring schedule. A risk‑based approach works well:

High‑impact rules (privileged access, production changes, incident handling) might be checked continuously or weekly.
Medium‑impact rules (patching timelines, backup tests, training completion) might be sampled monthly or quarterly.
Low‑impact rules may be monitored through occasional audits and during management reviews.

What matters is that you can explain your rationale and show that the chosen mechanisms actually operate in practice. When customers or auditors ask why a rule is checked monthly rather than weekly, you want a clear, risk‑based answer.

Prioritising and aligning with governance

Most MSPs cannot move everything to a continuous‑assurance model at once, so prioritisation matters. You will make faster progress by focusing on the rules that would cause the most damage if ignored and building confidence there first.

A pragmatic approach is to:

Identify the five to ten rules whose failure would most damage customers or your own business.
Focus initial design and automation efforts on those rules.
Choose monitoring, reporting and escalation processes that tie directly into existing governance.

For example, you might start by:

Linking privileged‑access rules to your identity and ticketing systems so that every elevation is approved, logged and reviewed.
Connecting patching standards to your RMM tool, with dashboards that show compliance across customers and flag exceptions.
Reporting key metrics – such as the number of policy violations and age of open exceptions – into your ISMS committee and management reviews.

By doing this, you make A.5.36 part of your normal planning and oversight, rather than a separate language that only the ISO team speaks. Staff and customers then see a consistent storey: rules, checks, evidence and improvements all connected in a way that aligns with the Plan–Do–Check–Act cycle.

A Practical A.5.36 Framework for MSPs

A practical A.5.36 framework gives you structure for how rules, owners, checks and responses fit together across your MSP. It turns scattered policies and habits into a clear map of who is responsible for what, how compliance is checked and how you respond when things go wrong.

This framework becomes the bridge between high‑level policies and the operational steps engineers and service managers follow. It also gives you a repeatable way to answer customer and auditor questions without reinventing explanations each time.

Building an MSP‑specific A.5.36 control framework

An MSP‑specific A.5.36 framework usually starts with a simple register that shows how important rules are applied, checked and evidenced in practice. Each entry links a rule to services, owners, monitoring and evidence.

A useful starting point is a register that, for each important rule, captures:

The policy or standard it comes from.
The services and customer environments it applies to.
The control owner responsible for enforcement.
The process owner responsible for design and effectiveness.
The monitoring mechanism and frequency.
The evidence sources, such as reports or ticket types.
The exception process, including approval and review dates.

For MSPs, this register should explicitly include customer‑specific requirements, not just your generic corporate policies. If a major customer requires you to meet particular logging standards or change‑control rules, those obligations should appear as rules in your framework, with owners, checks and evidence sources.

For example, a “privileged access” rule might be captured as coming from your access‑control policy and a key customer schedule. It might apply to SOC and infrastructure services, be owned by the Head of Security, be monitored weekly through identity and ticketing reports, be evidenced by access reviews and change approvals, and have time‑limited exceptions approved by the CISO.

You do not need hundreds of entries. Start with the rules that matter most for security and assurance, especially where your contracts and marketing claims are strongest. Over time, you can expand the register as needed, based on risk and customer expectations.

An ISMS platform such as ISMS.online can strengthen this further by holding the register, linking rules to risks and controls and tracking review dates and changes. That shared view reduces confusion and makes it easier to maintain alignment as your services evolve.

Defining scope, ownership and breach criteria

Two parts of the framework deserve particular care: ownership and what counts as a breach. Both determine whether your rules remain theoretical or actually shape behaviour.

Strong ownership means every significant rule has:

A control owner, accountable for ensuring the rule is followed across relevant services.
A process owner, accountable for keeping the control design and monitoring approach appropriate as technology, customers and regulations change.

Equally important are clear breach criteria. You need an agreed way to distinguish between:

Minor deviations that can be handled locally and recorded as part of normal work.
Significant breaches that should be logged as nonconformities, escalated and potentially treated as incidents.

You cannot enforce what you have not defined as a breach. Defining thresholds in advance makes it easier to configure tools, such as how alerts are classified and routed, and to ensure disciplinary and contractual measures are applied consistently and fairly. It also makes it easier to link A.5.36 into your incident management and nonconformity processes so that serious breaches follow the same structured path as other security events.

A framework like this cuts down on re‑work at audit time. When auditors or customers ask, “How do you make sure this rule is followed?” you can point to a clear description that shows the rule, the controls, the monitoring and the evidence, then pull a few samples to demonstrate that the cycle is operating.

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

Book your demo

Embedding A.5.36 into the ISMS, Governance and SOPs

Embedding A.5.36 into your ISMS, governance structures and standard operating procedures is how you turn frameworks into real‑world behaviour. The aim is to make policy compliance part of routine decision‑making and service delivery, not an isolated compliance activity that only appears before audits.

Many of the necessary mechanisms already exist in a typical ISO 27001‑aligned MSP: risk registers, change‑management processes, incident management, disciplinary procedures, internal audits and management reviews. The task is to connect A.5.36 explicitly into those mechanisms so that non‑compliance with rules is handled as a first‑class risk, not an afterthought.

Linking A.5.36 into risk and management processes

Linking A.5.36 into existing risk and management processes makes it easier to govern non‑compliance consistently. Rather than creating a separate track, you surface policy breaches alongside other risks and control issues.

Step 1 – Integrate rule breaches into risk management

Add typical “policy non‑compliance” scenarios to your risk register, such as failure to follow access‑control rules or change‑control processes. Link them to existing risks – for example, data breaches or service outages – so you can justify monitoring and mitigation efforts and make sure ownership is clear.

Step 2 – Make A.5.36 a recurring audit theme

Ensure internal audits and compliance reviews regularly test whether selected rules are being followed. Sample a small number of rules each year and check that documented controls, monitoring and evidence operate as described. Use findings to drive corrective actions and improvements, not only to label past behaviour.

Step 3 – Feed metrics into management reviews

Include A.5.36‑related metrics – policy‑violation counts, exception trends, completion of planned checks – as standard inputs into management reviews. Discuss what they say about culture, controls and workload, and decide where to focus improvement efforts. Doing this consistently shows auditors and customers that non‑compliance is actively governed.

It is also important to ensure your ISMS scope statement and context analysis explicitly include services delivered to customers and the tools used to deliver them. That way, there is no ambiguity about whether A.5.36 applies to multi‑tenant platforms, customer environments and subcontracted services.

Making A.5.36 part of everyday workflows

Making A.5.36 part of everyday work is ultimately about aligning runbooks and behaviours with the framework so that compliance becomes part of “how we do things here”.

Useful techniques include:

Annotating runbooks: Tag steps in onboarding, change, incident and maintenance runbooks that exist to satisfy particular rules. Simple identifiers, such as rule IDs or policy references, make it easier to maintain alignment when policies and standards change.
Updating forms and workflows: Ensure that key processes capture the information you need for A.5.36 evidence – such as which policy a deviation relates to, what corrective action was taken and whether an exception was granted.
Role‑based training: Move beyond generic “security awareness” courses. Provide short, role‑specific guidance on what A.5.36 means for engineers, service managers, account managers and sales. Show them how their actions generate or consume evidence and how that supports customers.

Over time, this makes compliance feel less like an extra task and more like part of how you deliver quality services. It also makes it easier to automate checks and reporting, because the necessary data is already flowing through your tools in a structured way.

An ISMS platform can help by housing the framework, linking rules to risks, controls, runbooks and evidence, and by providing a common place for nonconformities, corrective actions and management‑review records. That shared context reduces the risk of different teams working from different versions of the truth and makes A.5.36 visible to both technical and non‑technical stakeholders.

Tooling: Turning Policies into Machine‑checkable Rules (SIEM, RMM, ITSM)

Turning policies into machine‑checkable rules means expressing key parts of your policy set as conditions your tools can monitor and enforce so you reduce manual checking and gain stronger assurance that rules are being followed. Once you have clear rules, ownership and processes, you can start expressing some of those rules as technical conditions your tools can check, so A.5.36 and your security‑operations stack reinforce each other, turning policies into machine‑checkable signals.

The goal is not to build a separate “compliance system” but to configure the systems you already use – SIEM, RMM, identity platforms, endpoint management and ticketing – so they produce evidence and alerts that map back to your rules and standards. Done well, this reduces manual effort and increases confidence that rules are actually enforced.

Expressing policies as technical conditions

You express a policy as a technical condition by going from plain‑language rule to specific signals and checks in your tools. The pattern is simple, but applying it consistently takes discipline.

To translate policy text into something tools can work with, it helps to use a pattern that bridges language and configuration:

Start with a rule: for example, “all managed endpoints must run approved endpoint protection”, or “no shared admin accounts are allowed”.
Identify signals: decide which logs, configuration data or events would show whether the rule is being followed or breached.
Define conditions: write clear conditions that can be tested, such as “agent present and healthy” or “more than one person using the same privileged account”.
Configure checks: implement those conditions in your monitoring and management tools, with dashboards or reports that summarise compliance and highlight exceptions.
Connect to workflows: route violations into ticketing queues with appropriate categories, priorities and SLAs, so they are handled like any other operational issue.

For example, consider the rule “all managed endpoints must run approved endpoint protection”. The signals might be agent health data from your RMM and antivirus console. The condition is “agent installed and reporting within the last 24 hours”. You configure checks and dashboards to flag missing or stale agents and create tickets automatically, so non‑compliant devices are visible, tracked and remediated.

The same logic applies to process‑based rules. For example, a rule that “all high‑risk changes must go through a formal approval workflow” can be checked by correlating change tickets with deployment logs and flagging deviations.

Start with a small number of high‑impact rules and tune thresholds carefully. Over‑sensitive checks that generate constant alerts will quickly lose credibility and can make assurance look worse rather than better.

Using your tools to detect and enforce rules

Many MSPs already have the tools needed to support A.5.36; what is usually missing is the explicit mapping from rules to tool configuration and reports, and the discipline to keep that mapping updated.

Useful opportunities include:

Remote monitoring and endpoint management: Use these to enforce and report on patching standards, encryption, endpoint protection deployment and local admin rights across customers. Exceptions become visible, quantified inputs into risk and governance processes.
Security analytics and logging: Configure correlation rules that group likely policy violations – such as out‑of‑hours privileged access or configuration changes without associated tickets – into focused dashboards. These can be reviewed in daily or weekly routines.
Identity and access management: Use group membership, conditional‑access policies and role‑based access controls to enforce rules around who can do what, where and when. Logs and reports then form part of the evidence pack for access‑control‑related rules.
Ticketing and IT service management (ITSM): Ensure tickets that represent non‑compliance are tagged with the relevant rule, tracked through to closure and retained for analysis. Over time, this creates a structured history of how rules are applied and enforced.

Automated enforcement – such as blocking actions that violate key rules or quarantining non‑compliant devices – can be powerful for the highest‑risk areas. When you implement such controls, documenting their design, scope and monitoring gives you strong material for both auditors and customers under A.5.36.

ISMS.online does not replace these operational tools, but it can sit above them, storing the rules, mapping them to services and controls and linking to the reports, dashboards and tickets that show how they operate. This avoids the need to re‑implement monitoring while giving you a coherent compliance storey that joins technology and governance.

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

Book your demo

KPIs, Records and Evidence for Auditors and Enterprise Customers

A small, well‑curated set of metrics and records will do more for A.5.36 assurance than dozens of loosely related charts and screenshots, because the right measures help you show that rules matter, are checked and lead to action when they are not followed. Consulting guidance on ISO 27001 and wider cyber‑risk management also tends to favour focused, decision‑relevant metrics over large volumes of unstructured data for exactly this reason, as that combination is easier for boards, auditors and customers to interpret.

With rules expressed and checks in place, you can then shape the resulting data into measures and evidence that satisfy two demanding audiences: certification auditors and enterprise customers.

Almost all respondents to the 2025 ISMS.online survey listed achieving or maintaining security certifications, such as ISO 27001 or SOC 2, as a top priority.

The goal is a lean set of measures and artefacts that demonstrate three things:

You know which rules matter.
You check compliance with them.
You act on what you find, and you learn.

The strongest assurance stories are the ones you can tell consistently, not the ones you reinvent for every customer.

Designing a lean A.5.36 metrics set

A lean A.5.36 metrics set focuses on a handful of indicators that speak clearly to risk, behaviour and improvement. Too many measures dilute attention and are hard to maintain.

You do not need a long list of KPIs. A small, carefully chosen set can be more powerful and easier to maintain, especially when you must explain it repeatedly to auditors, boards and customers.

Examples that work well for MSPs include:

Policy and training coverage: Percentage of staff and key roles that have acknowledged and completed training on relevant policies and standards.
Violation rates: Number and severity of identified breaches of key rules over a period, broken down by service or function.
Time to remediate: Average time from detection of a breach or nonconformity to resolution.
Exception landscape: Number of approved exceptions against rules, their age and when they are due for review.
Monitoring coverage: Proportion of in‑scope systems or customers covered by defined checks.

These metrics can be presented differently for different audiences. Boards and executives care about trends and business impact. Technical teams care about where to focus effort. Customers care about assurance that rules are followed and improved over time. Linking metrics such as exception age or monitoring coverage to commercial outcomes – for instance, how they affect due‑diligence findings or contract renewals – makes their relevance clearer.

Regular internal reviews of these measures help identify systemic issues, such as repeated breaches of the same rule or particular services that struggle to stay within standards. Those insights should feed into targeted improvements in training, process or tooling.

Building reusable evidence packs

Reusable evidence packs let you respond quickly and consistently to assurance requests. Instead of assembling ad‑hoc bundles under pressure, you maintain a core A.5.36 storey that can be tailored to each auditor or customer.

Auditors and customers alike appreciate structured, reusable evidence. Instead of starting from scratch for each assessment, you can prepare an A.5.36 “evidence pack” that you update periodically and tailor to the audience.

A typical pack might include:

A concise explanation of how A.5.36 is implemented in your MSP, with diagrams showing the framework and key processes.
Excerpts from your policy and standards register, highlighting rules that apply to services in scope.
Samples of training and acknowledgement records for relevant staff.
Selected monitoring reports demonstrating checks against key rules.
A small set of redacted tickets showing how non‑compliance is logged and resolved.
Summaries of internal audits or compliance reviews that tested A.5.36‑related controls.
Evidence that management has reviewed policy‑compliance metrics and taken decisions on improvements.

For customers, you can further anonymise and tailor this material, focusing on the rules and services relevant to them and on how your MSP‑wide governance supports their specific requirements. An anonymised example from a similar customer – such as a mid‑size MSP with SOC and managed detection and response services – can help illustrate how your framework operates in practice without revealing confidential details.

ISMS.online helps by allowing you to store control descriptions, link them to evidence records, track review dates and export consistent views when needed. It also supports your own internal assurance, because you can see at a glance which rules have up‑to‑date evidence and which need attention before the next audit or customer review.

Book a Demo With ISMS.online Today

ISMS.online gives your MSP a practical way to turn A.5.36 from a paper exercise into a visible, manageable control across your services. It helps you move from point‑in‑time, people‑dependent compliance towards continuous assurance that matches how you already run security operations.

In practice, that means you can:

Keep your policy and standards set in one place, mapped to services, risks and ISO 27001 controls.
Assign clear ownership for rules and controls, with tasks and workflows that track reviews and improvements.
Link rules to real‑world evidence such as audits, monitoring reports and tickets, without duplicating operational data.
Build and maintain reusable evidence packs for auditors and customers, cutting preparation time and reducing stress.
Support management reviews and board reporting with up‑to‑date views of policy‑compliance metrics and nonconformities.

Seeing this in the context of your own services is far more powerful than reading about it in the abstract. A demo gives you the chance to walk through your A.5.36 challenges, see how they map into the platform and explore what a more continuous, tool‑supported assurance model would look like for your organisation.

If you lead security, operations or compliance in an MSP and need to strengthen how you demonstrate A.5.36 to auditors and enterprise customers, booking a demo is a practical next step. It lets you test whether ISMS.online can help you show – not just say – that you comply with your policies, rules and standards for information security across every managed service you deliver.

Frequently Asked Questions

What does ISO 27001:2022 A.5.36 really require from an MSP on a day‑to‑day basis?

A.5.36 expects your MSP to prove that people actually follow your security rules in daily work, and that you routinely detect, assess and fix non‑compliance across your own estate, your toolchain and your customers’ environments.

Where does A.5.36 show up in a real MSP?

For a managed service provider, this control bites in three places at once:

Your internal environment

This is everything your team uses to run and support services:

Access to PSA, RMM, SIEM, backup, identity and ticketing platforms.
Laptops, servers, VPNs and SaaS used by engineers and back‑office staff.
How people handle customer data in email, chat, documentation and screen shares.

Here A.5.36 is asking: do you have clear rules for how staff access and protect this estate, do they understand them, and can you show how you check and improve them over time?

The multi‑tenant service stack you operate

This is the shared tooling layer you drive on behalf of many customers:

RMM, EDR, SIEM, identity, cloud admin consoles, backup platforms and ticketing.
Rules for MFA on consoles, admin role design, use of break‑glass accounts, supplier access and change approvals.
Alignment between your service catalogue, runbooks and what actually happens on tickets and out‑of‑hours changes.

Here the expectation is simple: documented rules, clear owners, defined review cadences, and evidence that exceptions are recorded, assessed and either closed or accepted as risks.

Customer environments in scope

This is the infrastructure and cloud workloads you manage under contract:

Devices, networks, tenants, subscriptions and security controls you are responsible for.
SLAs and runbooks that define what “secure enough” means for each service.
Evidence that patching, monitoring, backup checks, access reviews and incident handling match what you have promised.

Across these three layers, auditors, cyber insurers and enterprise buyers are really looking for three things:

MSP‑specific rules: that talk about remote access, multi‑tenant tooling, customer data handling and use of subcontractors.
Evidence that people follow those rules: – training, policy acknowledgements, worked ticket and runbook examples, access‑review records.
A traceable loop: showing that when rules are broken, you log it, assess the risk, take action and adjust controls or training.

When you can explain that loop in plain language and back it with a small, well‑chosen set of examples, A.5.36 becomes a way to show customers you run your MSP with discipline, rather than just another checkbox on the Annex A list.

How can an MSP shift from annual “paper compliance” to continuous assurance without burning people out?

You shift to continuous assurance by moving away from a once‑a‑year scramble and instead wiring smaller, risk‑based checks into the tools and workflows your teams already use, so useful evidence appears automatically as they do their jobs.

What does continuous assurance look like in an MSP?

A practical model usually rests on three moves.

Use risk‑based cadences instead of flat checklists

Not every rule deserves weekly attention:

High‑impact domains: – privileged access, high‑risk changes, backups for key tenants, monitoring coverage – justify continuous, daily or weekly checks.
Medium‑impact domains: – patch compliance, configuration baselines, completion of security training – fit monthly or quarterly cycles.
Lower‑impact areas: – some physical controls or niche tools – can be sampled in internal audits and spot checks.

This shows you are putting A.5.36 effort where customer risk and trust demand it, not just where a template said “monthly”.

Build checks into the tools your teams already live in

Continuous assurance only survives if checks are part of normal work:

Change approvals, out‑of‑hours admin use and exceptions are enforced via ticket workflows with mandatory fields and approvals.
Baselines and patch rules are enforced and reported in RMM and endpoint security tooling, not copied into spreadsheets.
Admin and identity events – new privileged roles, MFA changes, risky sign‑ins – are tracked via audit logs and SIEM rules tuned to a small number of meaningful patterns.

The goal is that your ISMS and any Annex L‑aligned IMS use these existing signals rather than creating a parallel universe of manual logs that no one trusts.

Let evidence be a by‑product of good operations

When checks are wired into your platforms:

Tickets, dashboards, reports, change records and review notes become A.5.36 evidence by default.
Your ISO or security lead stops being an “evidence hunter” and becomes a control tuner, using this stream to tweak thresholds, cadences and training.

If your team already dreads the weeks before surveillance audits or large customer reviews, you can position continuous assurance as a way to make life calmer and more professional, not another layer of compliance admin. ISMS.online is designed to sit on top of this model by linking risks, policies, internal audits and corrective actions in one place, so that continuous checks in your tools naturally feed your information security management system.

Which concrete checks and records should an MSP focus on first for A.5.36?

You do not need a wall of binders. You need a small, disciplined set of checks and records that prove rules exist around high‑risk areas, are applied in practice, and are corrected when they are not.

Which domains usually matter most in audits and due diligence?

Five areas typically carry the most weight for an MSP.

1. Privileged and remote access

This is usually the first place auditors and customers look.

Define: who can hold admin accounts, what MFA and device standards apply, how shared credentials are avoided, and how emergency access is requested and revoked.
Keep: admin group membership exports, short access‑review minutes, and a few redacted tickets showing emergency access opened and closed.

2. Patching and configuration

This shows whether you can execute basic hygiene at scale.

Define: minimum patch cycles by system type, baseline configs for endpoints, servers and cloud, and how exceptions are handled.
Keep: patch and vulnerability reports with clear scope and dates, plus tickets where drift from baseline was found, risk‑assessed and fixed.

3. High‑risk change management

This is where many serious incidents start.

Define: which changes require formal approval (for example, firewall rules, identity changes, backup policies), who approves, and what must be recorded.
Keep: a small set of fully populated change tickets showing the journey from request to sign‑off and, where required, post‑implementation review.

4. Logging and monitoring coverage

This proves you notice and act when something goes wrong.

Define: which events must be logged for your own estate and for managed services, where logs land, how long you retain them and which alerts matter.
Keep: simple coverage diagrams or summaries, example alerts, and follow‑on tickets that show how the issue was investigated and closed.

5. Exceptions and non‑compliance

This is where A.5.36 really shows whether you take rules seriously.

Define: how exceptions are raised, approved, time‑boxed and reviewed, and how repeated non‑compliance is escalated.
Keep: a living exceptions log linked to your risk register, and a few cases where you not only fixed the immediate problem but changed a template, updated a runbook or adjusted training.

When you pull these into a compact A.5.36 “evidence pack” and keep it current, you can answer auditors, cyber insurers and enterprise procurement teams quickly without inventing new evidence each time. In ISMS.online, that pack can sit alongside your relevant policies, risks, internal audits and management reviews so your team always knows where to go when someone asks, “Show me how you know your policies are followed.”

How should an MSP embed A.5.36 into its ISMS and IMS so it survives staff changes?

A.5.36 lasts beyond any one ISO lead when you treat it as part of your governance rhythm, not a side project. That means wiring policy compliance into risk management, internal audit, incident and change handling, and management review so it is regularly discussed and acted on.

What does that look like in an Annex L‑aligned MSP?

Three design choices make a noticeable difference.

1. Treat patterns of breach as risks, not noise

Rather than treating repeated policy breaches as “annoying one‑offs”:

Capture recurring themes – unmanaged admin accounts, unapproved changes, repeated patch delays, backup failures – in your risk register with explicit customer and business impact.
Assess them like any other ISO 27001 risk: likelihood, impact and control effectiveness, so “we got away with it” is not the metric.
In an Annex L‑aligned IMS, link those risks to related clauses in quality, service management or business continuity standards so the same weakness is not quietly undermining several certificates.

2. Put A.5.36 on the agenda for management review and internal audit

Policy compliance should be a standing topic, not just an appendix.

In management reviews, include simple, trendable indicators: count and severity of policy breaches, exception ageing, overdue control checks and internal audit findings related to rules not followed.
Use internal audits to sample real services, tools and customers and check whether rules are genuinely applied there, not just in your most mature accounts.
Turn review outputs into tracked actions: who owns a fix, when it is due, how progress will be checked, and how success is measured.

ISMS.online supports this pattern by giving you management review templates, linked risks, internal audits and corrective actions in one place, so you can show the loop from issue to improvement.

3. Tie SOPs and runbooks directly to controls and contracts

Engineers need to see how their steps map to obligations.

Annotate onboarding, change, incident and maintenance steps with the policy, Annex A control or contract clause they satisfy.
Update forms so they capture the data you will later depend on: which rule applied, who approved, which tenant was affected, what was done to prevent recurrence.
Reflect these expectations in role‑based training so staff understand why certain fields and approvals are mandatory, not “extra admin”.

When this structure lives inside your ISMS and any wider IMS – instead of scattered across documents and people’s heads – A.5.36 turns into “how we run the MSP”, not “what we dust off for the auditor”. If you use ISMS.online, you can make those links explicit through linked work, risk records, internal audits and management reviews, which helps you show continuity even when roles change.

How can SIEM, RMM and ticketing tools become practical enforcement engines for policy rules?

You turn existing platforms into enforcement engines by translating a small set of important rules into conditions those tools can check automatically, and by ensuring any failure becomes a clear, actionable ticket with ownership and a feedback path into your ISMS.

What pattern can an MSP follow to make rules machine‑checkable?

A simple six‑step pattern works across most domains.

1. Write the rule so a human and a tool can both apply it

For example:

“All managed Windows servers must apply critical security updates within 14 days of release, unless an approved exception exists.”
“Each customer tenant must have at least two named global admins, both protected by MFA and conditional access.”

Avoid ambiguous phrases like “where feasible” if you want tools to help.

2. Decide which signals prove the rule right or wrong

Look at what your systems can already see:

RMM or vulnerability scanner patch data.
CMDB or asset inventory content.
Directory and SaaS admin roles, sign‑in and configuration logs.
Tickets and exceptions in your service desk.

These signals define what can be automatically checked.

3. Turn the rule into concrete, testable conditions

Examples:

“Every in‑scope server appears in the inventory, has a current agent and shows no critical unpatched vulnerabilities older than 14 days.”
“Any server with an overdue patch has either an open, approved exception or a remediation ticket with an owner and SLA.”
“Every tenant has at least two unique global admins with MFA enforced; no generic accounts hold admin roles.”

This step creates the bridge between policy words and tool logic.

4. Build dashboards, queries and rules in your tools

Implement those conditions in your platforms:

Dashboards in RMM and vulnerability tools that surface non‑compliant assets and let teams drill down.
SIEM correlation rules or scheduled reports that highlight policy‑relevant anomalies, such as new privileged accounts without MFA or large changes outside change windows.
Ticketing workflows that enforce approvals and capture the right fields when certain categories are raised.

Now “checking compliance” is a matter of looking at live views, not assembling ad hoc spreadsheets.

5. Route failures into meaningful tickets

When something fails the test, it should create a ticket that someone can act on:

Tag tickets with the rule and control they relate to (for example, “ISO 27001 A.5.36 – privileged access”).
Include context: customer name, asset ID, severity, how long it has been in breach, and links to any related exceptions.
Set realistic SLAs and owners so these tickets are not buried under low‑value noise.

This is the part A.5.36 cares about: you not only detect breaches of your own rules, you fix them in a controlled way.

6. Keep enough history to show trends and learning

Evidence that controls work comes from history:

Retain dashboards, reports and tickets long enough to show improvement or recurring themes, and to support internal audits.
Use a handful of well‑chosen cases – including at least one uncomfortable example – in management reviews, supplier due diligence and customer meetings to show that policy breaches lead to action and learning.

Over time, this pattern builds a catalogue of machine‑checkable rules covering privileged access, backup verification, EDR deployment, log coverage and more. ISMS.online helps by linking these controls and their evidence back to your policies, risks and Annex A controls so you can present them as part of a coherent information security management system, not a pile of disconnected screenshots.

How can an MSP turn ISO 27001 A.5.36 into a clear commercial advantage with ISMS.online?

You turn A.5.36 into a commercial advantage by being able to calmly walk auditors and customers from “here is the rule” to “here is how we enforce it and what we do when it is broken” – and by doing that from a single, structured environment you can reuse across audits, tenders and reviews. ISMS.online is built to be that environment.

What does that look like in audits, RFPs and customer reviews?

Three habits consistently make MSPs stand out.

Use one mapped view from rule to service to evidence

Instead of juggling folders and spreadsheets when someone mentions A.5.36:

Maintain a single, structured register of policies, standards and service‑specific rules in ISMS.online, with named owners, scopes and linked evidence sources.
Link each rule to relevant Annex A controls, risks, internal audits and corrective actions using linked work.
When an auditor or enterprise customer asks, open that map, then click into a few live examples – access reviews, change tickets, training acknowledgements – to show the path from written rule to actual behaviour.

This level of traceability makes you look like an MSP that runs on a real ISMS, not just on good intentions.

Show how you respond when rules are broken

Buyers increasingly want to understand how you behave on bad days:

Use ISMS.online to keep a structured log of policy breaches and exceptions, with fields for impact, root cause, owner, treatment and closure.
Bring a couple of carefully redacted cases into meetings to show how issues were detected, what you did immediately, and how you strengthened controls or training afterwards.

Handled well, these examples build trust; they show you treat A.5.36 as a living discipline, not a marketing slogan.

Reuse your A.5.36 work across frameworks and customers

Because ISMS.online supports ISO 27001 and Annex L‑aligned Integrated Management Systems, every improvement you make for A.5.36 plays double duty:

Other frameworks and regulations: – SOC 2, NIS 2, DORA or sector‑specific standards often ask similar questions about how you follow your own rules; you can answer from the same linked records.
RFPs and cyber insurance: – security questionnaires that probe policy adherence can often be answered by exporting or summarising your existing ISMS.online evidence.
Customer reviews and QBRs: – you can reuse parts of your A.5.36 evidence pack to show how you protect each customer’s environment over time, not just at certification milestones.

If you want to be seen as the MSP that “can actually show how they work”, it makes sense to give your team a platform designed for that level of transparency. Exploring how ISMS.online can underpin your A.5.36 approach – alongside your broader information security management system and any Annex L‑style integrated management system – is a practical way to move from basic certification to a more defensible, commercial storey about how you run security for yourself and your customers.

A.5.36 Compliance With Policies, Rules and Standards for Information Security – MSP Assurance