Why are MSP backups suddenly under so much pressure?
Managed service providers are under new pressure because clients, regulators and attackers now treat backups of logs and configurations as key evidence of reliability. You are expected to prove that these data sets are protected, restorable and trustworthy whenever something goes wrong, not just that servers come back online.
Strong backup stories are ultimately stories about trust, not storage.
This article offers general information about backup governance for MSPs. It is not legal, regulatory or insurance advice, and you should obtain specialist advice before making high‑stakes decisions.
Over the last few years, several service‑provider incidents have revealed the same pattern. A customer suffers an outage or compromise, the MSP restores core servers reasonably quickly, but the logs and configuration data needed to understand, prove and fully recover the incident were either never backed up or sat on the same storage that failed. Independent MSP incident case studies repeatedly highlight this pattern, showing how missing or destroyed logs and configs turn recoverable faults into long‑running trust crises. That turns a technical problem into a trust problem. Boards and security leaders at your customers now explicitly ask: “If something goes wrong, can you show us what happened and rebuild us to a known‑good state?”
Expectations have risen in parallel. Customers often assume that every meaningful piece of information you touch-security logs, SaaS audit trails, firewall rules, identity configurations and infrastructure‑as‑code-is being backed up, retained and tested. Many MSPs, by contrast, still treat logs and configurations as “ephemeral” or “re‑derivable”, focusing their formal backup regimes on file servers and databases. Industry surveys on MSP backup practices and client assumptions, such as backup‑expectation studies for MSPs, show a consistent gap between what customers believe is protected and what providers actually back up. The gap between those assumptions is where audit findings, tense QBR conversations and lost deals live.
Attackers have also learned to go after backup platforms and log stores directly. Ransomware crews try to disable or corrupt backup jobs, wipe snapshots and tamper with security logs. Threat reports on backup‑platform abuse, including analyses like ransomware targeting backup systems, describe attackers logging into consoles, deleting retention jobs and corrupting archives before triggering encryption. An “all green” status in a backup console is worth little if it can be spoofed or if log and configuration backups sit in the same blast radius-meaning the scope of systems hit by one failure or attack-as production. Customers and auditors have started to look past vendor labels and ask for evidence that backups are designed and operated with these threats in mind.
Regulators and insurers are adding further pressure. Many sectoral rules and incident‑reporting regimes now assume that organisations can reconstruct a period of events from logs and restore services using preserved configurations. Regulatory guidance on log retention and incident handling, such as incident‑response expectations for log data, increasingly treats the ability to replay events from logs and rebuild from stored configurations as a basic prerequisite. When your customers outsource operations to you, they rely on your backup posture to meet those obligations. Their internal risk registers increasingly reference third‑party backups as a line item, and vendor‑risk reviews probe deeply into how you handle logs, configurations and restore testing.
In the 2025 ISMS.online survey, about 41% of organisations named managing third-party risk and tracking supplier compliance as one of their top security challenges.
All of that means backup is no longer a quiet, technical niche. It is part of how customers judge your reliability, how auditors judge your control maturity, and how your own board judges your exposure. ISO 27001:2022 control A.8.13 – “Information backup” – has become one of the lenses through which they do it. Commentary on A.8.13 for service providers, such as service‑provider‑focused interpretations of the control, explicitly notes that customers, auditors and insurers now use this control to assess how well MSPs preserve the information needed for recovery and investigation. In the following sections, you will see what that control actually demands of you as an MSP, and how you can turn those demands into a clear, defensible backup standard for client logs, configurations and operational systems.
How did backups move from simple housekeeping to a strategic MSP concern?
Backups shifted from background housekeeping to a strategic MSP concern because complex estates, public incidents and tougher customers exposed how much recovery and investigations depend on more than file servers. What used to be a quiet nightly task is now a multi‑platform discipline with direct commercial impact.
Backups used to be a straightforward operational job: run nightly jobs, rotate media, send copies off‑site and occasionally test a restore. The scope was mostly obvious-file servers, application databases, maybe some virtual machines-and customers rarely asked detailed questions. The environment was simpler, and so were expectations.
Today, your estate likely spans on‑premises infrastructure, multiple public clouds, SaaS platforms, modern identity systems, security tools and a long list of edge devices. Logs and configuration data live in many places: SIEM indices, firewall and VPN devices, admin portals, configuration‑management systems and code repositories. Many of those systems are now business‑critical in their own right. Losing their history or baselines can be as damaging as losing a file share.
At the same time, clients have become more educated. They bring their own auditors, cyber‑insurance questionnaires and internal standards. When they ask “Do you back everything up?” they rarely mean “Do you back up the file server?” They mean “Can you recover our ability to operate safely and prove what happened if something goes wrong?” That is a much broader, more demanding question, and it is exactly the space A.8.13 pushes you to think about.
The shift is not only technical. It changes how customers and auditors evaluate you. Backup decisions now influence renewals, vendor‑risk scores and your ability to compete for larger, more regulated customers.
Why do logs and configurations matter so much in outages and investigations?
Logs and configurations matter so much in outages and investigations because they answer two core questions after an incident: what happened, and how do you safely get back to where you were? Without them, recovery becomes guesswork and trust is hard to rebuild.
When something serious happens-a ransomware attack, a critical misconfiguration, a cloud outage-two questions dominate for your customers and their stakeholders:
- How quickly can we get back to a safe, working state?
- How do we know what actually happened?
Logs are your primary source for answering the second question. They show which accounts were used, which IPs connected, what changes were made and which systems were touched. If key logs are missing or incomplete, you may never be able to prove the scope of an attack, satisfy investigators or a customers board, or demonstrate that regulatory duties were met.
Configurations are central to the first question. They define how firewalls philtre traffic, how identity systems enforce access, how VPNs and SD‑WAN appliances route data, how SaaS platforms enforce security policies and how backup jobs themselves are configured. If you cannot quickly restore those baselines from a known‑good point, every recovery becomes a slow, manual reconstruction exercise, full of guesswork and risk.
In many of the most painful incidents, the data – files, databases – were restorable enough. The real damage came from missing or inconsistent logs and configurations. Post‑incident forensic reviews, including analyses of firewall‑configuration loss and SIEM log gaps, often show that the absence of these artefacts turned otherwise manageable events into prolonged crises with unclear scope and delayed recovery. Interpreted for MSPs, A.8.13 is partly about making sure that does not happen to your customers, and that you can prove it when you are under scrutiny.
Logs and configurations, treated as first‑class backup objects, therefore become a core part of your incident‑response and assurance storey, not just technical detail in the background.
Book a demoWhat does ISO 27001 A.8.13 really ask of MSPs for logs and configs?
ISO 27001 A.8.13 expects you to define, operate and demonstrate a backup regime that covers information, software and systems in line with an agreed policy. For MSPs, that includes client logs and configurations wherever they are needed for recovery, monitoring or compliance, not only traditional data like file shares and databases.
The 2025 State of Information Security report indicates that customers increasingly expect their suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials and SOC 2.
ISO 27001:2022 Annex A control A.8.13 says, in essence, that backup copies of information, software and systems must be maintained and regularly tested in line with an agreed backup policy, so that you can recover after loss or interruption. MSP‑focused interpretations of the standard, such as service‑provider commentaries on A.8.13, restate this as a requirement to design and test backup arrangements that can withstand realistic failure and threat scenarios, rather than just existing on paper. For an MSP, that requirement applies both to your own information and to the systems and data you manage on behalf of customers.
In practical terms, A.8.13 expects you to decide, document and demonstrate what you back up, how, how often, how long you keep it, how you protect it, and how you prove it can be restored. Client logs and configuration data fall within that scope whenever they are necessary to meet agreed recovery objectives, security monitoring needs or legal and regulatory duties.
To make that concrete, it helps to break the control down into four questions:
- Scope: Which information, software and systems are in backup scope, and why?
- Operation: How are backups performed, protected and monitored?
- Testing: How do you verify that restores work and meet recovery objectives?
- Evidence: How do you show auditors and customers that all of the above actually happens?
For MSPs, those questions have to be answered twice: once for your own internal ISMS, and once for the services you provide to clients. Many of the underlying processes and tools will be shared, but the risks, obligations and expectations are different. That is why you need an MSP‑specific interpretation of A.8.13 rather than relying on generic enterprise guidance.
A structured ISMS platform such as ISMS.online can help you link A.8.13 policies to assets, risks and controls, so scope and responsibilities for logs and configurations are clear and traceable across your client base. If you want a single place to define those expectations and keep the evidence aligned, centralising them in such a system is often the most practical option.
How should you interpret A.8.13 in an MSP context?
In an MSP context, you should treat any client information needed for recovery, detection or legal duties as in scope for A.8.13, align backup with related controls such as logging and change management, and document shared responsibilities clearly in policies and contracts.
First, treat any information you manage for clients that is necessary to restore services, detect and investigate incidents or meet formal retention duties as in scope for A.8.13. That usually includes:
- Security logs from firewalls, VPNs, endpoints, intrusion‑detection tools and SIEM platforms.
- System and application logs with evidential or operational value for incidents or audits.
- Configuration data for network devices, security tools, virtualisation platforms, identity systems and critical SaaS services.
- Templates and infrastructure‑as‑code that define standard builds and baselines.
Taken together, these items form the backbone of your ability to prove what happened and to rebuild safely.
Second, recognise that A.8.13 does not live in isolation. It meshes with controls on logging, change management, access control, business continuity and supplier relationships. For example:
- Logging controls require you to retain important logs; A.8.13 asks how you restore them after outages.
- Change‑management controls track configuration changes; A.8.13 preserves known‑good versions.
- Business‑continuity controls define recovery objectives; A.8.13 is one way you meet those objectives.
This alignment helps you avoid duplicated work and conflicting expectations across standards and services.
Third, the phrase “topic‑specific policy on backup” is important. It means you should not hide backup expectations inside a general information‑security policy. You should have a dedicated backup policy or standard that references logs and configurations explicitly, describes responsibilities, and sets out how requirements are derived and applied.
Finally, be clear about shared responsibility. In some scenarios, clients will retain responsibility for backing up data in certain SaaS applications or internal systems. In others, you may manage the platform but the client owns decisions on retention or specific log sources. A.8.13 does not force you to take on every possible backup duty, but it does expect you to be explicit about who does what, to cover those splits in contracts and policies, and to manage residual risk. MSP‑oriented readings of A.8.13, including interpretive notes for service providers, stress this dual obligation across your own ISMS and the environments you manage.
Where do client logs and configurations fit into backup scope?
Client logs and configurations fall into backup scope wherever losing them would break recovery objectives, weaken security monitoring or breach legal and regulatory expectations. That scope should be explicit in your backup policy, not assumed or left to individual engineers.
Many MSPs have historically treated logs and configurations as separate from backups:
- Logs were seen as something that lived in SIEMs or monitoring tools, not as backup objects.
- Configurations were assumed to be reproducible from documentation or scripts, not treated as primary data needing backup.
Under A.8.13, those assumptions are no longer safe. If a log stream or configuration set is necessary to restore services, investigate incidents, prove compliance or achieve agreed RPO/RTO targets, it should be explicitly covered by your backup regime.
That does not mean you must back up every log generated by every device for the same length of time. It does mean you should:
- Identify which log sources are critical for security, operations and compliance.
- Decide which of those need independent backup beyond the local device or primary log store.
- Specify retention periods based on risk, regulation and customer requirements.
- Include those decisions in your backup policy, asset inventories and service descriptions.
Summarising this clearly in your standard avoids assumptions and surprises when an incident or audit arrives.
The same logic applies to configurations. Certain device types-firewalls, VPN gateways, core switches, identity systems, backup platforms themselves-are linchpins of your clients’ security and continuity. Their configurations need to be backed up, versioned, protected and periodically test‑restored with as much care as any database.
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.
How do you move from “we do backups” to a master backup standard?
You move from “we do backups” to a master backup standard by defining one MSP‑wide baseline for scope, frequency, retention, protection, testing and evidence, then applying it consistently across clients with controlled variations for tiers and contracts.
About two-thirds of organisations in the 2025 ISMS.online survey said the speed and volume of regulatory change are making compliance harder to sustain.
To comply with A.8.13 at scale and to reduce commercial risk, you need to move away from ad‑hoc, per‑customer backup habits towards a single master backup standard for your MSP. That standard sets the minimum expectations for how information, including logs and configurations, is backed up and tested across all clients, and defines the parameters that can vary by service tier or contract.
A master backup standard is not a marketing brochure; it is a governance tool. It tells your engineers what they must do, your sales teams what they are allowed to promise, your compliance function what to evidence, and your customers what they can expect.
At a minimum, it should cover:
- Scope and data classes.
- Backup frequency and methods.
- Retention periods and destruction rules.
- Protection measures such as encryption, access control, segregation and immutability.
- Monitoring and exception handling.
- Restore testing, including sampling of logs and configurations.
- Documentation and evidence requirements.
Once you have that standard, you can parameterise it per client: same structure, adapted values. Using a platform such as ISMS.online to hold that standard as a controlled document and link it to risks and controls makes it easier to keep policy, implementation and evidence in sync. If you want one place for engineers, auditors and sales teams to refer to the same backup rules, centralising them this way is often a pragmatic choice.
Why does a master backup standard matter commercially and operationally?
A master backup standard matters because it reduces blind spots, supports repeatable delivery and gives you a defensible position with auditors and customers. Without it, every client becomes a one‑off, increasing risk and cost.
Without a master standard, each client ends up being treated as a one‑off. Different engineers configure backups in slightly different ways. Salespeople make promises based on individual deals. Documentation lives in tickets and heads. When an audit or serious incident arrives, you may discover that backup coverage, retention and testing vary widely between customers, with no clear rationale.
That inconsistency is risky in several ways:
- It increases the chance that a critical log source or configuration set has been overlooked entirely.
- It makes it harder to prove to auditors or insurers that you have a deliberate, risk‑based approach.
- It inflates operational overhead, because every exception must be remembered and managed manually.
- It exposes you to allegations of unfair treatment if one client receives significantly stronger protection than another without a documented reason.
A master standard gives you a reference point. It makes your service catalogue clearer: each managed service includes defined backup expectations. It makes renewals and QBRs easier: you can show customers how their service tier maps to backup capabilities. It also gives your own leadership more confidence that you are not carrying silent, uneven risk across the client base.
What belongs inside a realistic MSP master backup standard?
A realistic master backup standard defines, for each data class, why you back it up, how you do so, how long you keep it and how you prove restores work. It should be clear enough for engineers and auditors to apply without guesswork, and simple enough to maintain.
When you draught your standard, focus on clarity and applicability. For each data class-security logs, operational logs, configurations, system images, databases-spell out:
- Objective: The purpose of backing up this data class.
- Scope: Typical sources included by default, and when explicit agreement is required.
- Frequency: How often backups or exports occur, expressed in plain terms.
- Retention: Minimum and maximum periods, linked to laws or contracts where relevant.
- Protection: Encryption, access control, segmentation and any immutability requirements.
- Testing: How often restores are tested and what success looks like.
- Evidence: Expected artefacts in an audit, such as policies, job configurations and sample reports.
Holding this standard inside an ISMS such as ISMS.online makes it easier to keep everything aligned as you grow. You can link it directly to Annex A.8.13, related controls and specific client services, so the same backbone supports sales, delivery and assurance.
A well‑structured standard also becomes an internal checklist for onboarding new services and platforms, making it much harder for critical log sources or configurations to fall through the cracks.
How do you make RPO/RTO real for logs, configs and systems?
You make RPO and RTO real by classifying data, defining a small set of realistic tiers, and testing whether your backup and restore processes actually meet those targets for logs, configurations and systems across clients.
Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are the backbone of any serious backup strategy. For MSPs, the challenge is to translate those concepts from policy language into concrete, testable behaviours for different types of client data-especially logs and configurations.
RPO is about how much data you can afford to lose, expressed in time. RTO is about how long you can afford to be without a system. For many clients, these values will differ across applications, environments and data sets. For you, the job is to design a small number of backup tiers that can realistically meet those mixed demands without collapsing under complexity.
For logs and configurations, this often means accepting that you will not treat every source equally. Some logs are critical for security and must be near‑real‑time and long‑retained. Others are useful but not essential. Some configurations change frequently and are high impact; others are relatively static. Your RPO and RTO tiers should reflect those differences, and your backup regimes should match.
Clear objectives for loss and recovery times stop RPO and RTO being vague promises on paper and turn them into concrete targets you can build and test against.
Why should you classify data before setting RPO and RTO?
You should classify data before setting RPO and RTO because classification lets you apply a few sensible targets across many systems instead of drowning in per‑source exceptions and unrealistic promises.
If you try to set RPO and RTO values directly against every individual source system, you will drown in permutations. Instead, classify data into a few business‑meaningful classes. For example:
- Class A: Critical security and compliance evidence.
- Class B: Operational logs and configurations required for continuity.
- Class C: Lower‑impact logs and configurations where re‑creation is possible or impact is limited.
Once you have data classes, you can assign default RPO, RTO and retention targets to each. These targets should be based on customer use cases, regulatory expectations and your technical capability, not on wishful thinking. You can then adjust per client when there is a strong reason, using a formal exception mechanism.
A simple way to communicate this is to build a table of classes and targets:
| Data class | Typical RPO / RTO tier | Example drivers |
|---|---|---|
| Class A | RPO ≤ 15 minutes, RTO ≤ 4 hours | Security investigations, compliance logs |
| Class B | RPO ≤ 4 hours, RTO ≤ 24 hours | Continuity for core operations |
| Class C | RPO ≤ 24 hours, RTO ≤ 72 hours | Troubleshooting, lower‑impact workloads |
You can use this model in client discussions and internal design sessions. It gives engineers a clear target for each class and gives auditors something understandable to test against.
How do you keep RPO/RTO targets honest and achievable?
You keep RPO and RTO targets honest by modelling capacity, aligning sales with engineering, measuring actual performance and including realistic restore tests that cover logs and configurations, not just easy workloads.
RPO and RTO figures are easy to type and hard to deliver. To avoid over‑promising:
- Model capacity and performance.: Estimate data volumes per class, client counts, backup windows, bandwidth and storage behaviour as you grow.
- Align sales with engineering.: Offer only approved RPO and RTO bands by default, and route tighter requests through review and sign‑off.
- Measure real performance.: Track achieved RPO (age of last good copy) and RTO (time to restore) per tier and client, and correct bottlenecks.
- Test restores realistically.: Include logs and configurations from high‑impact environments in your restore exercises, and record end‑to‑end timings.
For example, for Class A security logs and firewall configurations, you might define an RPO of fifteen minutes and an RTO of four hours. You would then design log collection, archive jobs and configuration exports to support those numbers, and run periodic tests where you restore a firewall configuration to a lab device and replay a day of logs into a test SIEM to confirm the targets are realistic.
For clients, explain RPO and RTO in scenarios rather than numbers alone. For example: “If this firewall is misconfigured at 10:00, our target is to restore its configuration from a last‑known‑good copy no more than 15 minutes old, and have it back in service by 11:00.” That makes responsibilities and trade‑offs much clearer.
Once you have credible RPO and RTO bands, the next step is to design backup architectures that can deliver them consistently across many tenants, not just in a single lab scenario.
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.
How can you design multi‑tenant backup architectures for logs and configs?
You design multi‑tenant backup architectures by deciding where to centralise or isolate, how to separate client data, how to capture configurations, and how to preserve the integrity of log evidence across all tenants using patterns that balance security with efficiency.
As an MSP, you rarely operate a single, neat environment for a single organisation. You run a multi‑tenant landscape: many clients, many platforms, many tools. A.8.13 does not tell you how to architect backups in that context, but it does expect you to deliver and evidence reliable, secure, testable backups across all relevant tenants.
The core architectural questions are:
- How do you separate client data to avoid cross‑tenant exposure or accidental deletion?
- Where do you centralise for efficiency, and where do you isolate for safety?
- How do you capture, protect and version configuration data?
- How do you ensure log backups maintain integrity and evidential value?
- How do you monitor health and readiness across the whole environment?
You do not need to overhaul your tools to answer those questions, but you do need a deliberate design that can be explained and defended to auditors and customers.
What patterns support secure segregation and efficient operations?
Secure, efficient multi‑tenant patterns use per‑tenant segregation of data and keys on top of shared tools and pipelines, so you can balance security with manageable complexity in day‑to‑day operations.
Most organisations in the 2025 ISMS.online survey reported being impacted by at least one third-party or supplier security incident in the past year.
Segregation and efficiency tend to pull in opposite directions. Strong segregation pushes you towards per‑tenant instances and strict separation of storage, keys and admin roles. Efficiency pulls you towards shared infrastructure, centralised pipelines and common tooling. Most MSPs land on a hybrid approach:
- Use per‑tenant encryption keys and logically separated repositories so one client’s compromise cannot easily affect another’s backups.
- Centralise log collection where it makes sense, but tag and store archived copies in ways that keep tenant boundaries clear.
- Separate operational log retention from security log retention if you need tighter control over evidence.
- Minimise and audit high‑privilege accounts that can alter backup jobs or delete archives.
Whatever patterns you choose, document them in architecture diagrams, threat models and operations runbooks. That documentation is part of your A.8.13 evidence and underpins your “backup assurance” claims to customers.
How should you handle configuration backup in a diverse, cloud‑heavy world?
You should handle configuration backup by treating configurations as primary backup objects, automating exports, storing them securely and including them in restore tests, rather than assuming they can always be recreated from scripts or documentation.
Configuration backup is often the weakest link in MSP recovery. It is easy to assume that cloud platforms and managed devices will remember their own policies, or that scripts and infrastructure‑as‑code repositories are “good enough” as documentation. In practice, you should:
- Automate regular exports or snapshots of configurations for critical systems and platforms.
- Store configuration exports in version‑controlled, access‑controlled, ideally immutable storage.
- Link configuration versions to change‑management records for traceability and rollback.
- Include configuration restores in your testing programme, not only full system recoveries.
Treat configuration artefacts as first‑class backup objects, with data classification, RPO and RTO, and retention rules like any other class. Doing so means that when you face a complex incident, you can go beyond “we can rebuild it by hand” and instead say, “We can restore it to this known‑good state from this time, and here is the evidence.”
As your cloud footprint grows, this discipline also protects you against accidental changes in provider consoles and ensures that knowledge is not trapped in individual engineers’ heads.
How do you prove backups work and build audit‑ready trails?
You prove backups work by combining clear policies, complete scope, monitored jobs, meaningful restore tests and well‑organised evidence, so auditors and customers can see that A.8.13 is operating in practice, not just on paper.
Only about one in five organisations in the State of Information Security 2025 report said they avoided data loss entirely over the last year.
From an auditor’s perspective, effective information backup is not just about having tools configured. It is about being able to show that:
- Your policies and standards exist and are applied.
- The right systems and data are in scope.
- Backups actually run, are monitored and are fixed when they fail.
- Restores are tested, and tests meet defined success criteria.
- Evidence is complete, accurate and traceable.
For MSPs, that evidence has to be reusable across audits, customers and internal reviews. If you assemble it from scratch every time, you will become exhausted and inconsistent. A structured evidence pack for A.8.13 helps avoid that and makes future assessments easier to handle.
What should an A.8.13 evidence pack contain for logs, configs and systems?
An A.8.13 evidence pack should contain the core documents and records that show what is in scope, how backups run, how issues are handled and how restores are tested, with explicit coverage for logs and configurations where they matter most.
A practical evidence pack will usually include:
- Policies and standards: Your master backup policy and any supporting standards that reference logs and configurations explicitly.
- Asset inventories: Lists of systems, log sources and configuration repositories in backup scope, with data classes and assigned RPO, RTO and retention tiers.
- Backup job definitions: Screenshots or exports showing how jobs are configured for representative clients-what is included, where it goes, how often it runs.
- Monitoring and reporting: Samples of backup reports and dashboards for selected periods, showing success rates, failures and how exceptions are handled.
- Restore test records: Logs and reports from restore exercises, including which items were restored, how long it took and whether objectives were met.
- Change records: Evidence that changes in scope trigger backup updates, or that exceptions are recorded and approved.
To make this concrete, imagine one representative client. Your evidence pack might show the relevant section of the backup policy, the asset list for that client’s firewalls and SIEM, the job configuration for exporting and archiving those logs and configurations, a monthly backup report highlighting any failures and fixes, and a recent restore‑test log where a firewall configuration and a day of logs were restored to a lab environment and validated.
If you use ISMS.online, you can keep these artefacts linked to A.8.13 and related controls, so you can retrieve everything quickly when an auditor or demanding customer asks for proof, rather than rebuilding the storey from scratch every time.
How can you make restore testing meaningful without burning engineers out?
You make restore testing meaningful by sampling sensibly, including logs and configurations, automating where possible and feeding results back into design, so tests strengthen your regime instead of becoming a box‑ticking chore.
Restore testing is where many backup regimes fall short. It is easier to show that jobs ran than to prove that restores will work as expected. To make testing effective but sustainable:
- Scope your programme.: You do not need to test every client and every system every month; rotate by class and tier.
- Include logs and configurations.: Do not limit tests to server images or file shares; cover evidence that matters most.
- Automate and log well.: Use scripting and orchestration to spin up temporary environments and capture timings.
- Feed results back.: Use test outcomes to improve architecture and adjust RPO and RTO claims where necessary.
For example, you might design a quarterly test where you restore a key client’s firewall configuration and 24 hours of security logs into a lab, validate the configuration against your baseline and confirm that the logs allow an analyst to reconstruct a predefined scenario. Records from that test strengthen both your operational confidence and your audit‑readiness.
Over time, a disciplined but realistic testing programme becomes one of your strongest assurances for customers, insurers and regulators.
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.
How can you offer backup assurance without unlimited liability?
You offer backup assurance by defining what is in scope, how it is protected and tested, and what residual risks remain, instead of promising to prevent every loss. That approach lets you give customers confidence without accepting open‑ended liability you cannot truly control.
Customers increasingly ask for “backup assurance”: confidence that their data, logs and configurations will be recoverable within agreed limits, supported by tangible evidence. Guidance for customers on evaluating MSP promises, such as backup‑assurance evaluation guides, reflects this trend by urging buyers to look for documented standards, test records and clear RPO/RTO commitments rather than vague assurances. At the same time, you cannot reasonably accept open‑ended liability for every possible scenario or data gap. The art is to define assurance in terms of design, process and proof, rather than absolute guarantees.
Backup assurance, sensibly defined, means that you can answer questions like:
- What is in scope for backup for this service and client, and why?
- What RPO, RTO and retention targets apply?
- How are backups architected, protected and monitored?
- How often have you tested restores for comparable systems, with what results?
- What residual risks remain, and who owns them?
It cannot honestly mean “we promise never to lose any log or configuration, ever”, which would be neither realistic nor insurable. Instead, you position yourself as a provider with a strong, evidence‑backed regime and clear boundaries.
How do you frame backup assurance in customer conversations?
You frame backup assurance by walking customers through your standard, data classes and responsibilities in practical terms, using realistic scenarios rather than vague guarantees or unbounded commitments.
Start by explaining your master backup standard and how it applies to the client in front of you. Show them how their services fit into your data classes and backup tiers, what that means in practice (for example, “critical firewall logs: near‑real‑time centralisation, retention for at least ninety days; firewall configurations: daily exports and monthly restore tests”) and where any deviations exist.
Be explicit about shared responsibilities. For example:
- You may back up core infrastructure logs and configurations, but the client is responsible for exporting and backing up certain application logs from SaaS systems.
- You may manage retention for certain log streams, but the client chooses the length of time based on their internal requirements and accepts the associated storage and performance costs.
Use real, anonymised examples where possible. For instance, walk through a hypothetical incident in which a compromised account changed firewall rules and then exfiltrated data. Explain which logs and configurations your backup regime would preserve, how quickly they could be restored and what that would enable the joint response team to do.
Most importantly, avoid vague assurances. Instead of “we always back everything up,” say “for this service, we commit to backing up the following data, on this schedule, with these retention targets, monitored in this way, and tested on this cadence.” That is both more honest and more compelling.
If you want those commitments and scenarios to be supported by a single, consistent set of policies and evidence across your customer base, an ISMS platform like ISMS.online can provide the structure you need.
How should you translate assurance into contracts and SLAs?
You translate assurance into contracts by describing scope, RPO, RTO and responsibilities precisely, aligning them with your backup standard and architecture, and using remedies that reflect what you can credibly deliver and evidence.
Your commercial documents need to reflect your technical realities. Vague phrases like “industry standard backups” or “best efforts” do little to protect either you or your customers. Instead:
- Describe scope precisely.: Name the systems, environments, log sources and configuration types that are included. Make clear what is excluded or requires explicit inclusion.
- Reference RPO, RTO and retention.: Use the values from your backup tiers, and link them to the services purchased.
- Define responsibilities.: Spell out who configures, monitors and maintains backups; who must notify of changes; and who decides on retention policies.
- Set realistic remedies.: Avoid open‑ended consequential‑loss clauses tied to backup failures. Instead, focus on service credits, re‑performance and cooperation in incident response.
- Align with policies.: Ensure your contracts do not promise more than your backup policy and architecture can deliver.
By doing this, you align A.8.13‑driven expectations with legally binding commitments. You also make it easier to defend your position after an incident: you can point to the agreed scope, show evidence that you followed it, and discuss any residual risk transparently.
Book a Demo With ISMS.online Today
ISMS.online helps you move from assumptions about backups to an evidence‑backed, auditable and commercially defensible backup model that aligns with ISO 27001 A.8.13 and related controls. By using one ISMS to define your backup standard, map it to services and store your evidence, you make it much easier to show customers and auditors that your regime is deliberate, tested and under control.
In the State of Information Security 2025 report, almost all organisations listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.
Within the same environment, you can hold your master backup standard, link it directly to Annex A.8.13 and related controls, and map that standard to specific services and customers. That gives your information‑security and compliance teams a clear view of how backup expectations for logs, configurations and systems are being applied in practice, and it gives auditors and demanding customers a structured way to review your posture.
For technical teams, centralising test plans and restore results removes a lot of friction. Engineers no longer have to hunt across tools to demonstrate that a particular configuration was backed up and successfully restored in a given timeframe. They can see, in one place, which tests have been run, what passed, what failed and what follow‑up actions were taken. That supports both internal assurance and external investigations.
You can also generate curated reports or controlled views for key clients. Instead of emailing screenshots or assembling bespoke slide decks, you can present a consistent “backup assurance” storey drawn from live data in your management system. That helps you answer difficult questions with confidence, without exposing sensitive details about other customers or internal workings.
Finally, workflow and task‑management capabilities mean backup‑related actions-such as reviewing exceptions, updating retention rules or scheduling restore tests-can be assigned, tracked and evidenced. That closes the loop between policy, implementation and proof, and shows that your backup regime is a living control, not just a document.
If you want to see how a structured platform could support your own approach to client logs, configurations and systems, exploring a demo of ISMS.online is a practical next step. It lets you compare your current A.8.13 coverage with a more deliberate, testable model and decide whether a centralised ISMS would help you build stronger, more visible backup assurance for your customers and your own organisation.
Frequently Asked Questions
Where does ISO 27001 A.8.13 really draw the line for MSP backups of logs and configs?
ISO 27001 A.8.13 expects you to treat client logs and configurations as first‑class information assets with a deliberately designed, documented and tested backup regime. That regime must show auditors exactly what is backed up, how often, where it’s stored, how it’s protected and how you know restores actually work.
How should an MSP define “information backup” for day‑to‑day managed services?
For a managed service provider, “information backup” is not limited to virtual machines or file systems. It covers any data and settings you would rely on to:
- Restore a customer’s service after an outage
- Investigate a suspected security incident
- Evidence your actions to a regulator or a court
- Prove you met your contractual obligations
That usually brings the following into scope:
- Security logs from firewalls, VPNs, EDR/AV, IDS/IPS and SIEM platforms
- Key application and platform logs needed for troubleshooting or forensic analysis
- Configuration data for switches, routers, firewalls and other network devices
- Directory and identity platforms such as Active Directory and Entra ID / Azure AD
- Tenant‑level configuration exports for important SaaS and cloud services
For each of these, an auditor will expect to see that you have:
- Decided and documented which logs and configuration sets matter for recovery and accountability
- Defined backup or forwarding methods (for example, SIEM pipelines, snapshots, API exports)
- Set retention periods, storage locations and ownership of those decisions
- Applied appropriate technical controls (encryption, access control, segregation, sometimes immutability)
- Planned and recorded periodic restore tests that include logs and configs, not just servers
You don’t need a different philosophy per client. A single backup standard in your ISMS that explicitly calls out logs and configurations as in‑scope assets under A.8.13, and then links to client‑specific scopes, jobs and restore evidence, is usually enough to satisfy auditors and reassure larger customers. ISMS.online helps by giving you one place to hold that standard, map A.8.13 to your control set and connect each client’s inventories, backup jobs and test records so your engineers, sales team and auditors all work from the same view.
How can an MSP standardise backup tiers when every customer wants different RPO and RTO targets?
The most sustainable approach is to design a small set of backup tiers with fixed RPO, RTO and retention bands, then assign each system, log source and configuration set to one of those tiers for each customer. That way you can offer meaningful choice without creating a unique pattern for every service.
How do you translate business impact into concrete backup tiers?
A workable starting point for many MSPs is three tiers such as:
- Tier 1 – Evidence and control plane:
Security logs, core network and firewall configs, identity platforms and other control‑plane components
– Typical RPO: minutes to one hour • RTO: a few hours
- Tier 2 – Continuity data:
Application logs and configurations that materially affect service availability or revenue
– Typical RPO: a few hours • RTO: next business day
- Tier 3 – Supporting logs:
Routine operational logs and low‑impact systems
– Typical RPO: daily • RTO: “best‑effort” for investigations only
For each tier you should define, in your ISMS:
- Recovery objectives (RPO/RTO) and minimum retention
- Permitted backup mechanisms (for example SIEM forwarding, scheduled exports, image snapshots)
- Storage and protection rules (region, encryption, logical segregation, optional immutability)
- Minimum restore‑test expectations across your client base
You then map each customer’s services, logs and configuration sets into these tiers and reflect that mapping in contracts, runbooks and security schedules. Instead of promising a custom RPO/RTO per asset, you can say “this service sits in Tier 1, which means…” and show tested evidence that supports that statement.
Modelling those tiers and mappings inside ISMS.online – and linking them directly to Annex A.8.13 – means any change (for example, moving a customer’s firewall from Tier 2 to Tier 1 after a risk review) is tied back to your backup standard, service definition and evidence pack. That alignment between what sales promise, what engineers operate and what auditors see is often the difference between a smooth audit and an uncomfortable one.
What specific evidence convinces ISO 27001 auditors that an MSP’s A.8.13 control is effective?
Auditors want to see that your backup regime for systems, logs and configurations is intentional, consistent and proven in practice. In a sampling‑based audit, that usually means a mix of written standards, inventories, configuration examples, monitoring outputs and restore‑test records that all tell the same storey.
Which artefacts should you have ready before the audit starts?
For a typical surveillance or certification visit, you should expect questions along three lines:
- Design and scope:
- A backup policy or standard that explicitly treats logs and configurations as information assets under A.8.13
- A service or client inventory showing which systems, log sources and configuration sets are covered, with their tiers
- Documented RPO/RTO targets and retention rules per tier or per service line
- Operation and monitoring:
- Representative backup job definitions (for example firewall configs, identity exports, SIEM pipelines, database snapshots)
- Monitoring views or reports over a defined period showing success and failure handling, with evidence of follow‑up
- Change records demonstrating that new services, tenants or log sources are brought into backup scope through a repeatable process
- Effectiveness and improvement:
- Restore‑test records that include logs and configurations, not just servers or databases
- Notes or actions from reviews where a test failed or highlighted a weakness and you changed something as a result
Auditors generally understand that incidents and failed jobs happen. What they look for is a coherent chain: the control is defined, the design is documented, the jobs run, failures are noticed, and realistic restore tests are carried out and acted upon.
If this information lives in different consoles, inboxes and personal folders, you and your team will feel under pressure every time an auditor asks for a sample. If instead you use ISMS.online to define the A.8.13 control once, attach your backup standard, link each client’s scope and job samples, and maintain a reusable “backup evidence pack”, you can answer most sampling requests from a single place and demonstrate that A.8.13 is under control rather than improvised.
How can an MSP promise meaningful backup assurance to customers without taking on unlimited risk?
You make backup assurance about evidence‑based design, monitoring and testing inside clear boundaries, not about promising that no data will ever be lost. Customers usually respond well to specific, testable commitments about scope and recovery levels, backed by current evidence, and they are more wary of broad guarantees that cannot realistically be honoured.
How do you shape an assurance storey that feels safe to customers and sustainable for you?
A practical assurance statement answers four questions in straightforward language:
- What we protect: Which systems, log sources and configuration sets are covered for each managed service
- How we protect them: The applicable backup tier, RPO/RTO, retention rules, storage locations and key technical controls
- How we keep ourselves honest: How backup jobs are monitored, how failures are escalated and how often restores are tested
- Where your responsibility starts: Data sources you must export or retain, regulatory choices that drive extended retention and the residual risks that remain
You can capture this in a short standard “backup and recovery overview” that appears consistently in proposals, security schedules and onboarding material. Behind that, your teams maintain a current backup tier mapping, live job status views and up‑to‑date restore‑test summaries for each customer.
Housing these elements inside ISMS.online and linking them to your A.8.13 control lets you show prospects, existing customers and, when needed, their auditors that your public commitments match the regime you actually run. That kind of precise, evidenced assurance tends to be more persuasive than a simple “we’ll never lose your data” line and it also helps protect your organisation if an incident is later examined in detail.
What retention and segregation patterns make sense for multi‑tenant backups of logs and configurations?
A workable pattern for most MSPs is to define a few risk‑based retention bands and combine them with strong logical segregation on any shared backup platforms. That combination usually meets security, privacy and regulatory expectations while still leaving room for justified contractual exceptions.
How do you balance investigative value, cost and privacy in a shared environment?
Many providers settle on an approach along these lines:
- Retention bands:
- A default window such as 90 days of online security logs across most tenants for day‑to‑day operations and basic investigations
- Extended retention, for example 12–18 months, for higher‑risk or regulated workloads such as payments, healthcare or critical infrastructure
- Shorter retention for low‑value operational logs where storage cost and privacy risk outweigh the investigative benefits
- Optional long‑term archives for specific “evidence” sources that certain customers must keep for legal, contractual or regulatory reasons
- Segregation and protection:
- Per‑tenant encryption keys or logically separate storage containers, vaults or accounts
- Strict access paths so engineers and SOC analysts only see one customer’s data at a time
- Role‑based access with least‑privilege roles for support, operations and monitoring functions
- Immutable or write‑once settings for key evidence stores where tampering or deletion would be particularly damaging
From an ISO 27001 perspective, the point is not only that these measures exist, but that you can describe and demonstrate them in a way that makes sense per tenant:
- Which log and configuration stores you hold for that customer
- How long each category is retained and in which locations
- How segregation and protection are implemented and checked over time
If you model this design in ISMS.online – using a single retention and segregation standard mapped to A.8.13 and cross‑referenced to individual customer scopes – it becomes much easier to justify your decisions to auditors, privacy officers and customers and to apply consistent changes when law, regulation or contracts evolve.
How do you turn Annex A.8.13 into a clear, repeatable managed backup service that sales and auditors both understand?
You treat A.8.13 as the backbone of a managed backup and recovery service, with named packages, defined RPO/RTO and retention bands (including for logs and configurations), and a standard assurance pack, all governed through your ISMS. That lets you move away from one‑off promises towards a stable catalogue of services that sales, delivery, customers and auditors all recognise.
What does a packaged, A.8.13‑aligned backup service look like in an MSP context?
A simple way to structure this is to define a small set of packages such as:
- Essential backup:
Core servers and critical configurations; limited log coverage; standard RPO/RTO and retention for smaller or lower‑risk clients
- Assured backup:
Servers plus higher‑value security logs and high‑impact configurations; faster RPO/RTO and a longer “evidence” retention tier for investigations and compliance
- Enhanced backup:
Broad log coverage, extended retention, immutable archives and more frequent restore tests for regulated or high‑risk customers
For each package you document:
- Which asset types are covered (systems, log sources, configuration sets)
- The applicable backup tier, RPO/RTO, retention and storage/protection expectations
- The division of responsibilities between your team and the client
- The monitoring and restore‑test practices that apply
- How the package maps to Annex A.8.13 and related areas such as logging, incident management and business continuity
You then:
- Capture the master backup standard and these package definitions once in ISMS.online
- Link client contracts, service catalogues and security schedules to the relevant package
- Maintain a standard evidence‑pack template that engineers and operations staff update as part of business‑as‑usual activities
Over time this gives you a consistent language in proposals and security questionnaires (“you’re on our Assured backup tier, which includes…”), a clear and reusable audit trail for ISO 27001 and a far easier onboarding path for new team members. It also positions your organisation as a provider whose backup commitments are not only confident but demonstrably controlled and repeatable – exactly the impression that informed customers and auditors look for when they ask what you do about A.8.13.
If you want a pragmatic way to move from theory to practice, you can start by drafting a single A.8.13 backup standard in ISMS.online, sketching your first three tiers or packages, and mapping just one high‑value client into that model. Once that pattern works for them, it becomes much easier to roll out across the rest of your managed services portfolio.
