A.8.10 Information Deletion: How MSPs Secure Client Data Offboarding

Often‑overlooked MSP client offboarding risks

Offboarding is risky for MSPs because client data often remains scattered across tools, backups and platforms long after contracts end. Even when you revoke access and close the last tickets, identifiers and content can still sit in places nobody is actively managing. If that data is later exposed or questioned, you will struggle to justify its presence to an auditor, regulator or former client. Client offboarding can feel finished when the final ticket closes, but for many MSPs that is exactly when residual risk grows. Data left behind in old systems, backups or note stores still sits under your control, even though you no longer have a legitimate reason to hold it, and ISO 27001 A.8.10 expects you to manage that end‑of‑life stage deliberately rather than leaving it to habit or memory. Independent summaries of ISO 27001, such as this overview of the 27001 control set, emphasise that information which is no longer required should be removed or rendered inaccessible in a planned, policy‑driven way rather than left to chance.

This article offers general guidance for MSPs on secure deletion and offboarding. It is not legal advice; you should confirm specific obligations with your own legal, privacy and regulatory advisers.

Risk does not disappear when a contract ends; it just changes shape if your data is left behind.

Why “offboarded” rarely means “data is gone”

“Offboarded” rarely means “all data is gone” because a typical MSP toolset leaves traces of a client in many different systems. Remote monitoring and management agents, support tickets, chat transcripts, documentation wikis, log archives, cloud snapshots and backup sets often retain identifiers, configurations and sometimes full data sets long after the contract ends. If you only turn off live services, you may still hold a substantial amount of information that should have moved into a planned deletion or anonymisation path.

For regulated customers, that residual data can become a problem in several ways. A later incident could expose records you were supposed to remove, a due‑diligence exercise could highlight “zombie” access paths, or an audit could ask for evidence that offboarded clients’ data was deleted in line with retention rules. Without a structured view of where information lives and how it is cleaned up, you are reliant on individual engineers’ memory and good intentions.

In the 2025 survey, only about one in five organisations said they had escaped data loss entirely in the previous year.

How incomplete offboarding becomes a real security and compliance issue

Incomplete offboarding becomes a serious security and compliance issue when access, data copies and unofficial workarounds continue to exist after the relationship ends. Old service accounts, automation keys or unmanaged notes can create attack paths that nobody owns any more. From an ISO 27001 A.8.10 perspective, this means information is still under your control even though there is no longer a legitimate reason to keep it.

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

Offboarding risk is not just about leftover files. Access paths can persist in subtle ways, for example:

shared admin credentials that remain valid on previously managed systems
API keys and service accounts for automation that are never revoked
third‑party SaaS portals that keep replicating data after the main service stops

Shadows of the old relationship can live on in ways that no single team member fully understands.

Shadow IT amplifies this. Technicians sometimes create ad‑hoc file shares, personal note stores or side‑channel backups to get work done quickly. If those locations are missing from your asset and data inventories, they will not appear in any offboarding checklist. Yet if information in those locations is exposed later, the client and regulator will still see it as your responsibility.

To manage this risk in a way that satisfies ISO 27001 A.8.10, you need to treat client offboarding as a high‑risk lifecycle event. That means understanding your real data surface, adding offboarding scenarios into your risk register, and designing controls that work across your full toolset, not just your core infrastructure. These risks are not only technical; they also shape how prospects and former customers judge your professionalism when they ask what really happens to their data at the end of the relationship.

Book a demo

Why information deletion is now a strategic differentiator

Information deletion is now a strategic differentiator for MSPs because it shapes who selects you, how audits feel and how smoothly relationships end. Buyers increasingly ask what happens to their data at exit, not just during live service, and security and privacy questionnaires increasingly include explicit questions on retention, erasure and end‑of‑contract handling, as reflected in shared‑assessment style guidance on data retention and GDPR‑aligned questionnaires such as this discussion of security questionnaires and data retention. If you can explain and evidence deletion clearly, you signal maturity, reduce friction and avoid disputes when contracts close, instead of treating deletion as quiet plumbing hidden behind more visible service metrics. Today it increasingly influences who selects you, how security due‑diligence proceeds and how costly disputes become, so for a growth‑focused MSP, being able to explain and prove deletion can be as important as demonstrating availability and uptime, especially where customers handle sensitive or regulated data.

The 2025 ISMS.online State of Information Security survey gathered responses from about 3,001 information‑security professionals across the UK and US.

How deletion and offboarding influence sales and renewals

Deletion and offboarding influence sales and renewals because security questionnaires, RFPs and stakeholder interviews increasingly probe your end‑of‑service practices in detail. Risk, privacy and legal teams want to hear a clear storey about data return, retention and destruction across production systems, backups and third‑party services. Enterprise and public‑sector buyers now routinely ask detailed questions about what happens to their information in backups, logs and third‑party platforms, not only in production. Shared‑assessment frameworks and questionnaire templates commonly probe how you handle long‑term storage, backup retention and third‑party data flows at and after contract end, reinforcing this expectation and making it harder to hide weak practices behind vague answers.

Clear deletion practices also support privacy and data protection expectations. Principles such as data minimisation and storage limitation require you to keep personal data no longer than necessary for the agreed purposes. These principles are explicitly reflected in GDPR and in commentary on retention and erasure obligations from regulators and privacy specialists, which stress that organisations should not keep personal data longer than necessary for stated purposes, as discussed in analyses such as this review of GDPR data retention and erasure duties. When you can explain that client information is either returned, anonymised or securely deleted at the right moment, you make a strong case to customer DPOs, legal teams and CISOs that your service will not create long‑term exposure for them.

From a relationship perspective, a simple, honest explanation of what you delete, what you retain and for how long reduces misunderstandings at exit. Disputes about “who still holds what” are often a sign that expectations were never aligned. Treating deletion as part of your value proposition allows account managers and vCIOs to position offboarding as a structured, predictable phase of the client lifecycle rather than a messy, adversarial ending.

Why a documented deletion storey builds trust

A documented deletion storey builds trust because it demonstrates discipline, transparency and respect for the client’s data. A well‑articulated offboarding storey does more than tick a compliance box; it shows you have a disciplined, respectful approach to other people’s information. When you can show that you:

understand where client data is stored
have agreed, written rules for retention and deletion
follow a repeatable offboarding playbook
can produce a concise pack of evidence if asked

you reduce the cognitive load on prospects’ risk and procurement teams. They spend less time chasing clarifications, and you spend less time rewriting bespoke answers. Over time, this shortens security due‑diligence cycles and positions your MSP as a safer long‑term partner.

This is also where a platform such as ISMS.online can help. By centralising policies, processes and records for deletion and offboarding, you can support commercial teams with consistent, pre‑approved language and artefacts instead of reinventing explanations for every opportunity. That alignment with a live management system also signals to auditors that your deletion storey is part of ongoing governance, not just a sales narrative.

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

A.8.10 ‘Information deletion’ decoded for MSPs

ISO 27001:2022 Annex A.8.10 requires you to delete or anonymise information when it is no longer needed, using secure and planned methods. It looks brief on paper, but for an MSP with multi‑tenant tools, backups and cloud services it carries wide implications, because information in your systems, devices and storage media must be removed when no longer required, using methods that are appropriate to each environment in a tool‑rich, multi‑tenant landscape where data passes through many hands and platforms. The control text and common implementation notes make clear that information which is no longer required for business, legal or regulatory reasons should be securely removed or anonymised in line with documented procedures, a point that is echoed in independent ISO 27001 summaries such as this control‑by‑control overview.

What A.8.10 really expects you to do

A.8.10 expects you to manage the whole information lifecycle: collect, use, store, back up, archive, and eventually delete or anonymise data when it is no longer required. “No longer required” should be defined by your retention policy as well as any stricter legal, contractual or regulatory obligations. You then need practical methods and evidence to show this is actually happening.

In practical terms, the control expects you to define:

which information you hold and where
when each category stops being required
how it will be deleted or anonymised
how you will demonstrate that this actually happens

For an MSP, scope includes client‑related information in production environments you host, in configuration repositories, in security tools, in monitoring platforms, in logs and backups, and in collaboration tools used to deliver the service. It also extends to relevant third‑party services where you control the relationship or configuration.

A.8.10 does not require perfection or immediate deletion of every copy at contract end. It does require that you have thought through how each type of information will be handled, that you apply appropriate methods, and that your decisions can be traced back to policy, retention rules and risk assessments.

How A.8.10 connects with other parts of your ISMS

A.8.10 connects closely to other ISO 27001 controls such as asset management, access restriction and backups. You cannot manage deletion well if you do not know which systems hold client data, who can access them and how long backups are kept. Deletion also interacts with supplier controls, because cloud and SaaS providers often play a role in how data is removed in practice.

Information deletion does not stand alone. It links tightly to controls for backup (such as A.8.13), logging and monitoring, access management (such as A.8.3), asset management, and supplier agreements. For example, your backup strategy determines how long data persists and how sanitisation occurs at the end of media life. Logging practices influence what personal data and client identifiers appear in long‑term archives. Supplier controls dictate how cloud providers and SaaS vendors handle deletion on your behalf. ISO 27001 implementation guides, such as this BSI implementation overview, highlight that deletion rules should be designed alongside backup, logging, access and supplier controls, because each layer influences how long information truly persists.

In an MSP context, lifecycle triggers are especially important. Common triggers include:

the end of a master services agreement
the end of a specific service such as managed backup
the expiry of a statutory or contractual retention obligation
the closure of a security incident or investigation

Each trigger should be reflected in your retention schedule and offboarding playbook so that teams know when to move from “retain” to “delete or anonymise”.

Around 41% of organisations in the 2025 ISMS.online survey named managing third‑party risk and tracking supplier compliance as a leading challenge.

It also helps to clarify the difference between deletion, anonymisation and pseudonymisation:

Deletion: removes data so it is no longer recoverable, for example securely wiping a disc.
Anonymisation: removes identifiers so the information can no longer be linked to a person or client, such as aggregating log data into metrics without IP addresses.
Pseudonymisation: replaces identifiers but still allows re‑identification with additional data, for example swapping usernames for reversible tokens.

Under A.8.10, anonymisation can often satisfy the requirement where you want to preserve trend data without keeping identifiable records. Guidance on anonymisation and data value notes that properly anonymised datasets can often be retained for analytics without breaching storage‑limitation expectations, provided individuals are no longer identifiable, as highlighted in discussions such as this article on why anonymisation matters for data‑driven businesses.

What to delete, retain or anonymise at contract end

At contract end, you need a clear, defensible policy on which data will be deleted, which will be retained and which will be anonymised, because the hardest questions are rarely technical: they centre on what you will delete, what you will keep and how you will justify those decisions if challenged later. If you can explain and document those choices in simple terms, offboarding becomes a predictable process rather than a tense negotiation, and that clarity also helps you align A.8.10 with privacy and contractual obligations.

Drawing a clear line between client data and MSP records

A clean offboarding starts by separating client‑owned data from the operational records your MSP legitimately needs. Client data should typically be returned or exported and then deleted from your systems once agreed retention periods expire. MSP records can be kept for defined business or legal reasons, but only in minimal form and under clear protection and deletion rules.

A practical way to start is to distinguish between:

information the client clearly owns and controls
operational records your MSP legitimately needs to retain

Client‑owned data usually includes production datasets, user files, mailboxes, application content and client‑specific backups that you maintained on their behalf. These should typically be returned or exported in a format agreed in the contract and then deleted from your systems once the retention period expires.

MSP‑owned operational records often include billing information, configuration notes, high‑level security events, change records and minimal logs needed to demonstrate how services were delivered. You may need these records for financial reporting, service quality analysis, later disputes or security investigations. Retaining them can be appropriate, but only if:

the categories are clearly defined in your data inventory
the retention period is justified by legal or business needs
the scope is minimised to what is genuinely necessary
the data is protected and deleted at the end of the defined period

This distinction helps you justify what stays, what goes and why. Treating every category as “keep just in case” undermines both A.8.10 and data protection principles.

The table below summarises typical outcomes for common categories of information at contract end.

Category	Typical examples	Default outcome
Client production data	User files, mailboxes, application content, client backups	Return or export, then delete after term
Configuration and monitoring	RMM configs, device lists, alert rules	Retain minimal view, then delete/anonymise
Operational service records	Tickets, change records, high‑level security events	Retain for defined period, then delete
Aggregate trend data	Anonymised metrics, incident statistics	Anonymise and retain for analytics

Exceptions, client preferences and evidence requirements mean your standard deletion timelines cannot be completely rigid. Legal holds, investigations or sector rules may require you to pause deletion for some records. Clients may want stronger or weaker deletion than your default. All of these need to be handled through structured options, documented approvals and clear review points.

Complexity increases when legal holds, regulatory investigations or sector‑specific rules apply. In those cases, your normal deletion timelines must be paused for the affected records while being carefully documented and time‑bound. You should record the reason for the hold, who authorised it, which information is in scope and when it will be reviewed. Once the hold ends, deletion or anonymisation should resume according to your policy.

Clients may also have different preferences. Some will want aggressive deletion of all material once they leave; others will expect extended retention of certain logs or incident histories. Rather than bending your process anew for each customer, you can define a small set of standard retention options, each with clear operational implications, and allow clients to choose within those limits during onboarding or contract renegotiation.

For every delete‑versus‑retain decision, it is wise to capture an evidence trail. Decision logs, approvals, references to relevant policies or contractual clauses, and links to supporting risk assessments can all live inside your ticketing or ISMS platform. When a question arises months or years later, you can show that the outcome was based on a structured, policy‑aligned process rather than personal preference.

Embedding this logic into your retention schedule and client data maps means offboarding teams no longer need to invent rules in the moment. They simply apply a documented model that has already been vetted by legal, privacy and security stakeholders.

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

Book your demo

Building a repeatable secure offboarding playbook

A repeatable offboarding playbook turns secure deletion from a stressful one‑off project into a standard part of your service lifecycle. Once you know what should happen to different categories of information, the next step is to package it into a playbook that teams can follow under pressure so they have a clear path from contract notice to verified deletion, even when relationships are tense or systems are complex. When the playbook is easy to follow, secure offboarding becomes predictable and auditable rather than heroic. That same playbook also provides material that feeds directly into internal audit and management review activities in your ISMS.

An effective offboarding workflow reflects the way MSPs actually work, with tickets, queues, handovers and time pressure. It should start from a clear trigger, progress through discovery and agreement stages, and finish with verified deletion. Each stage needs obvious owners and artefacts so that nothing depends on memory alone.

A practical offboarding workflow usually begins with a clear trigger, such as formal notice under the master services agreement. From there, you can define stages such as planning, agreement, execution and verification.

Step 1 – Planning and data discovery

Confirm the scope of services, identify systems holding client data and open coordinated tickets for each stream of work.

Step 2 – Agree handover formats and timelines

Agree export formats, delivery methods and deadlines so technical teams and the client share the same expectations.

Step 3 – Revoke or adjust access

Remove or adjust accounts, keys and roles across infrastructure, SaaS platforms and third‑party services in a controlled sequence.

Step 4 – Export data and obtain client confirmation

Export agreed datasets, deliver them securely and capture written confirmation that the client has received what they expect.

Step 5 – Delete or anonymise residual information

Apply your standard deletion and anonymisation methods across production, logs, backups and collaboration tools.

Step 6 – Verify and sign off

Validate that deletion worked, close tickets and record approvals so you can show what happened if questioned later.

Representing this flow as a simple swimlane diagram, with lanes for service desk, infrastructure, security, account management and legal, helps everyone understand how their actions mesh. It also reveals bottlenecks, such as dependencies on a single engineer or gaps where no one is explicitly responsible for validating deletion.

A responsibility model, such as RACI, makes ownership clearer still. One role might be accountable for authorising deletion once contractual obligations and legal holds are checked. Other roles will be responsible for implementing specific technical steps or for verifying evidence. When that model is embedded into runbooks, onboarding for new staff and the configuration of your PSA workflows, you avoid leaving critical decisions to whoever happens to pick up a ticket.

Making offboarding consistent, efficient and adaptable

To be useful, the playbook must feel realistic to the engineers and account managers who use it. It needs to handle awkward situations such as unpaid invoices, conflict with a departing client or unresolved incidents, while still ensuring that essential security work happens on time. You also need feedback loops so each offboarding improves the next.

Offboarding rarely happens in ideal conditions. There may be unpaid invoices, tense relationships or parallel incident investigations. Your design should anticipate those realities. For example, you might require that certain security steps, such as access revocation and data export, are not contingent on resolving commercial disputes, while still allowing you to pause non‑essential work if contracts permit.

Piloting the playbook on lower‑risk clients first can de‑risk adoption. You can track metrics such as time to complete offboarding, number of follow‑up tickets and quantity of residual accounts or data discovered after the fact. Lessons learned from early runs can feed back into refined checklists, better prompts in your PSA or additional training material.

Training and internal communications are vital. Engineers and account managers need to see offboarding as part of the normal service lifecycle, not as an unpleasant endgame. Short walk‑through sessions, visual guides and just‑in‑time prompts inside tickets or knowledge‑base articles help reinforce the process. Over time, a good playbook becomes a shared habit, not a document that only appears during audits.

Aligning this playbook with an ISMS platform such as ISMS.online lets you link each step to underlying controls, risks and evidence repositories. That way, your operational reality and your formal ISO 27001 documentation stay in sync, and practitioners can see how their daily work supports A.8.10 compliance.

Technical and procedural controls for verifiable deletion

Technical and procedural controls make deletion both secure and provable across your varied systems. You need standard methods for each storage type, clear rules for who can trigger deletion, and ways to show that actions worked, because a playbook only defines what should happen; controls ensure it actually does across diverse technologies, from on‑premises servers to SaaS platforms and long‑term backups.

Choosing and standardising deletion methods

Choosing deletion methods starts with understanding the storage and services you use: endpoints, servers, virtual infrastructure, cloud storage, SaaS and backups. Each needs an appropriate approach, from cryptographic erasure and secure wiping to lifecycle policies and provider‑managed purges. Standardising those approaches gives engineers confidence that they are doing the right thing under pressure.

Different types of storage and services demand different deletion approaches, for example:

endpoints and servers: secure wiping or cryptographic erasure of discs, plus removal from management tools
virtual infrastructure: careful handling of snapshots, volumes and images so de‑provisioning truly removes data
cloud object storage and file shares: lifecycle policies that expire data after defined retention periods
SaaS applications: administrative functions to purge user accounts, content and metadata

Backups are especially sensitive. You may not be able to surgically remove one client’s data from historical, multi‑tenant backup sets. Instead, your control could be to shorten retention for specific backup jobs, encrypt media with client‑specific keys and ensure that media are securely sanitised or destroyed at end of life. In many environments, cryptographic erasure through key destruction is a recognised way to render old backups unreadable, and can be a practical choice where re‑writing or overwriting every block is not feasible, in line with data‑sanitisation guidance such as NIST SP 800‑88, which includes crypto‑erase among accepted sanitisation methods.

In all cases, it is better to acknowledge technical constraints and manage them responsibly. Avoid promising perfect deletion you cannot deliver. Standardising these methods in a deletion standard or technical guideline helps engineers avoid ad‑hoc choices. For each data store type, you can document a primary deletion method, a fallback where the primary is not possible and the verification step required. Automation through scripts, RMM policies or orchestration tools can then apply those methods consistently and generate logs as they run.

Controls that make deletion provable

Deletion is only convincing to others when you can show when, how and by whom it was carried out. Procedural controls such as change records, dual approval, verification checks and logging turn technical actions into evidence. They also protect your team by making sure high‑risk deletions cannot happen silently or without review.

From an audit and client‑trust perspective, the most important question is not just “did you delete?” but “how do you know, and how can you show it?”. Several procedural controls help here:

change records or tickets for high‑risk deletions, referencing retention rules and approvals
dual control for key destruction or media disposal, so no one person can erase critical evidence
post‑deletion checks that accounts, searches or restores no longer reveal the client’s data
logs for automated and manual deletion jobs that can be exported into evidence packs

Monitoring also plays a role. Alerts for failed deletion jobs, unusual retention changes or anomalies in replication and backup behaviour should be routed to appropriate teams with clear runbooks. Periodic testing of deletion runbooks through exercises and sample restores verifies that controls still work as technologies and configurations evolve.

Bringing these elements together gives you not just the confidence that data is being deleted securely, but also the artefacts you need to convince others, from internal auditors to demanding enterprise customers.

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

Book your demo

Proving deletion and embedding it into your ISMS and contracts

Proving deletion means being able to tell a coherent, evidence‑backed storey about what happens to client data at exit, and that requires alignment across three layers: policies and standards, process artefacts and event‑specific records, all living inside your ISMS and echoed in your contracts so that what you promise matches what you can consistently deliver. Auditors, regulators and clients do not experience your intentions; they see your documentation and behaviour, so turning deletion into something you can prove depends on making A.8.10 clearly visible in each of those layers.

Auditors, regulators and clients do not experience your intentions; they see your documentation and behaviour. Turning deletion into something you can prove requires aligning your ISMS, contracts and operational evidence so that A.8.10 is clearly visible in each.

Building an audit‑ready deletion evidence pack

An audit‑ready evidence pack brings together high‑level rules, process design and specific records from an offboarding event so that when someone asks “show me what happened for this client”, you can retrieve all three quickly. This reduces stress for your teams, makes it easier to demonstrate that A.8.10 is operating in practice rather than just on paper, and an effective evidence pack for a specific offboarded client typically includes three layers:

Policy and standards.: Your information deletion policy, retention schedule and any technical standards that define methods and responsibilities. These show the principles you apply.
Process artefacts.: Your offboarding playbook, RACI, templates and any internal guidance that translate policy into action. These show the designed workflow.
Event‑specific records.: Tickets or change records covering the offboarding, approvals for deletion decisions, logs from systems showing deletion or expiry and any destruction or deletion confirmations issued. These show what happened in that case.

For example, you might hold a change ticket that references the master services agreement, points to the retention schedule, includes screenshots of backup job changes and log extracts from key systems, and ends with a formal sign‑off. That single package makes it much easier to discuss the offboarding with an auditor or former client than hunting through scattered emails and tools.

When these elements are linked inside an ISMS platform such as ISMS.online, you can move from a blank stare to a coherent storey when an auditor says, “Show me how you handled data deletion for the last client you offboarded.” The same pack, suitably summarised, can reassure an ex‑client who wants evidence that you have honoured your commitments.

Aligning contracts, ISMS and continuous improvement

Aligning contracts with your ISMS ensures that you only promise what your people and tools can reliably deliver. Data processing agreements and master services agreements should reflect your deletion model, including retention periods, backup behaviour and responsibilities in third‑party systems. If contract language drifts away from operational reality, you create risk for both parties. Contracting guidance on data protection obligations generally recommends aligning DPA language with the actual processing and deletion practices your organisation uses, so that contractual promises about retention and erasure are realistic and enforceable, as discussed in commentary such as this overview of contracting for data protection obligations.

Clauses should also align with privacy concepts such as storage limitation and rights related to erasure, while acknowledging legitimate retention needs and legal holds. Where laws or sector rules require you to pause deletion, that should be reflected in both your policy and your contractual wording.

About two‑thirds of surveyed organisations said the speed and volume of regulatory change are making compliance harder to sustain.

Contracts and data processing agreements should support, not contradict, your deletion model by describing:

what happens to different types of data at contract end
how long backups may continue to exist and under what protections
which party is responsible for actions in third‑party systems
what form of confirmation or reporting the client can expect

Those clauses should be written in consultation with both legal and operations, so that promises match what your playbook and controls can actually deliver. A simple principle helps here: only promise what you can consistently execute and evidence. Over‑ambitious or unclear wording may look attractive in sales conversations but creates serious compliance and liability issues later.

Within your ISMS, A.8.10 should not be an isolated item on a control list. Asset registers should indicate which systems hold client data and which deletion methods apply. Risk assessments should consider offboarding scenarios. Supplier reviews should check how downstream providers support your deletion obligations. Internal audits and management reviews should periodically test A.8.10 implementation, identify gaps and drive corrective actions.

By treating deletion as a living part of your management system, you create a feedback loop in which each offboarding event improves the next. That, in turn, makes your commitments to clients and auditors steadily more robust and reinforces your reputation for handling data responsibly throughout the relationship and beyond.

Book a Demo With ISMS.online Today

ISMS.online helps you turn ISO 27001 A.8.10 from a vague requirement into a live offboarding workflow with linked evidence that you can show to auditors and clients. By managing policies, playbooks, tickets and records in one place, you can make secure deletion a routine part of your service lifecycle instead of a stressful one‑off project.

What you can achieve in the next 90 days

In the next ninety days, you can turn deletion and offboarding from an ad‑hoc task into a standard, accountable playbook. You can confirm who is responsible for each step and align your retention and deletion rules with your contracts. Configuring these elements inside ISMS.online means they are not just documents on a shelf but active parts of your daily processes, with tasks, records and reviews driving consistent behaviour across your MSP.

A short working session with the ISMS.online team can help you map your current offboarding habits against A.8.10, highlight genuine gaps and prioritise changes that strengthen both compliance and profitability. Together you can identify a small set of metrics-such as offboarding cycle time, residual account discoveries and audit findings-that will show whether your new approach is delivering value.

Why see ISMS.online in action now

Seeing ISMS.online in action shows how an ISMS platform can make deletion and offboarding predictable, provable and easier to manage for your teams. A focused demo connects the ideas in this guide to your real client base, tools and contracts, so you can judge how well the approach will work in your specific context.

Strengthening information deletion and client offboarding today also prepares you for future frameworks and expectations. As regulations such as NIS‑aligned laws and customer standards evolve, having a structured, evidence‑ready deletion capability makes adaptation far easier than starting from scratch each time. If you are ready to be the MSP that can prove client data truly leaves when the relationship ends, booking a demo with ISMS.online is a practical first step.

Book a demo

Frequently Asked Questions

What does ISO 27001 A.8.10 really expect an MSP to prove about client data when a contract ends?

ISO 27001 A.8.10 expects you to prove that information which is no longer required is identified, handled in a controlled way, and evidenced – not just deleted informally when someone remembers. For a managed service provider, that means you can show where client‑related information lives, when each category stops being needed, and what happened to it at and after offboarding.

What does “no longer required” mean in an MSP context?

You’re expected to define “no longer required” in a way that would make sense to a regulator, auditor and lawyer:

You factor in statutory retention (tax, finance, employment, sector rules).
You align with contractual terms (limitation periods, SLA disputes, warranties).
You reflect legitimate business needs (security logging, service history, insurance).

Those rules should be visible in a deletion / retention policy and schedule that distinguishes between client content and your own operational records.

What does an auditor usually want to see for A.8.10?

Most auditors will want you to:

Point to a policy and retention schedule that cover client content and MSP records.
Show a repeatable offboarding workflow that references those rules.
Walk through a recent exit and provide:

The defined end‑of‑life rules for that information.
The steps you planned (export, retention, deletion, anonymisation).
The evidence: tickets, change records, logs, export lists, confirmations.

If you can calmly show “this is how we decide information is no longer required, this is the workflow we always run, and this is what we did for this client,” you’re meeting the spirit of A.8.10 far more convincingly than relying on “we usually delete things when a client leaves.”

How should an MSP decide what to delete, keep or anonymise when a client relationship ends?

You make those decisions by classifying information up‑front and applying simple written rules to each class, rather than improvising every time a contract ends. Without those rules, people either hoard everything “just in case” or delete too much and lose records you still need.

How do you separate client content from your own operational records?

A practical split most MSPs recognise is:

Client content: – information the client owns or is directly accountable for:
Tenant data, mailboxes, file stores and databases.
Virtual machines and hosted workloads.
Endpoint images and backups of their environments.
Customer‑specific monitoring and telemetry.

MSP operational records: – information you need to run and defend your business:
Contracts, invoices, time entries and purchase orders.
Aggregated logs and incident summaries.
Configuration notes, diagrams, runbooks and service reports.
Security events and change histories in your own platforms.

Client content is normally returned or exported, then kept recoverable for an agreed period before deletion. Operational records are kept in trimmed form for defined periods so you can:

Meet finance and tax rules.
Handle complaints, disputes and insurance claims.
Analyse security and service trends.

Documenting this split in your ISMS makes it much easier to explain to customers and auditors why different data sets follow different end‑of‑life paths.

When should you delete outright versus anonymise and keep?

For each information class, set out four basics:

Purpose: – why you hold it.
Retention period: – how long you genuinely need it.
End‑of‑life action: – delete, anonymise or move to a restricted archive.
Locations: – systems, storage and third parties.

Use deletion when there is no ongoing legal, contractual or operational reason to keep the information. Use anonymisation when you still want insight – for example, ticket trends or incident rates – but no longer need to identify a particular former client or individual.

The crucial point for A.8.10 is that these patterns exist before the exit, are written down, and are applied consistently. A platform such as ISMS.online makes this easier by linking information types, retention rules and end‑of‑life actions directly to your assets and controls, so your team always knows what should happen next.

How can an MSP turn client offboarding into a repeatable process that always includes secure deletion?

You make offboarding repeatable by treating it as a standard service workflow with a clear playbook, not as an occasional project that each engineer runs differently. That playbook should define stages, owners, artefacts and evidence so every exit includes secure deletion by design.

What does a practical offboarding playbook include for A.8.10?

A workable flow for most MSPs looks like:

Trigger and scoping:

A contract notice or non‑renewal creates an offboarding record in your PSA or ITSM tool. You capture scope, key dates, client contacts, in‑scope systems and any constraints (such as legal holds, regulators or open disputes).

Data and asset review:

You review the client’s asset and data map: tenants, environments, devices, backups, SaaS, monitoring and third‑party services. This clarifies where client content and your own records live.

Export and retention agreement:

You agree what will be handed back (data, documentation, credentials), in what format, how long data will remain recoverable and exactly when deletions or anonymisation will begin.

Access and configuration changes:

You remove or change accounts, keys, VPNs, integrations and monitoring in a planned sequence which doesn’t interrupt agreed exports or leave unmanaged access paths.

Execution of deletion / anonymisation:

You apply the retention rules: backing off backups, storage lifecycle policies, tenant‑level purges, device wiping, ticket redaction. Each action is recorded and, where needed, checked by a second person.

Closure and sign‑off:

You record what was exported, what was deleted or anonymised, what remains (with justification and retention period), and capture internal and – where appropriate – client acknowledgement.

Documenting this as a living workflow in your ISMS keeps the steps visible and auditable. In ISMS.online you can build that playbook directly into your control set and link it to change records, so A.8.10 is always backed by a traceable process rather than tribal knowledge.

How do you ensure engineers actually follow the offboarding playbook?

People follow processes they can see and that fit naturally into their tools:

Embed offboarding stages and checks into PSA/ITSM templates with standard tasks, fields and status codes.
Assign named roles for each stage – service desk, projects, platform, security, finance – so ownership is clear.
Surface completion of key access‑removal and deletion tasks in dashboards or service reviews.
Run lessons‑learned reviews on early offboardings to refine the workflow before applying it to more complex or regulated customers.

If you manage your ISMS in ISMS.online, you can link the offboarding workflow directly to A.8.10, assign owners, set review dates and capture evidence, so following the playbook becomes “how we do exits here” rather than a once‑a‑year clean‑up exercise.

Which technical and process controls give an MSP convincing proof that information really has been deleted?

You build convincing proof by combining robust technical controls with lightweight, repeatable procedures that always leave a trail. Customers and auditors want to see that you know what you did for a specific exit and can show it, not just that you own impressive products.

Which technical controls support trustworthy deletion evidence?

For most MSPs, the following are both practical and persuasive:

Storage and backup lifecycle policies: – automated expiry of data and backups after defined periods, with logs for policy changes and job results.
Cryptographic erasure: – retiring or destroying keys so encrypted data at rest can no longer be read, particularly in cloud platforms and self‑encrypting storage.
Vendor‑provided purge functions: – using built‑in tenant, account or workspace deletion in SaaS and cloud services rather than manual, item‑by‑item deletion.
Managed device sanitisation: – centrally controlled wipe, rebuild or secure disposal for laptops, servers, firewalls and network appliances you manage.

Well‑configured controls produce reports, logs or dashboards – for example, lifecycle jobs completed, keys destroyed, tenants removed – which you can attach to the offboarding record as part of your A.8.10 evidence.

What process steps make that proof more credible?

On the process side, you strengthen your storey if you:

Raise change records for significant deletions or key destruction, documenting approvals, scope and risk.
Apply dual control for high‑impact actions (such as wiping shared storage or retiring master keys) so no one makes those changes alone.
Include verification checks, such as confirming that:

The former client no longer appears in backup job lists.
Decommissioned accounts fail authentication.
Tenants or subscriptions have disappeared from management consoles.

Monitor deletion jobs and alerts, so failures or unexpected retention changes are picked up and fixed quickly.

ISMS.online helps here by letting you link these technical and process controls directly to A.8.10, store the associated evidence and review how well they’re running in internal audits and management reviews. That makes it easier to prove that deletion is something you do consistently, not only when someone asks hard questions.

How can MSPs package and present A.8.10 evidence so audits and client questions are quick to handle?

You make audits and former‑client questions easier by standardising an offboarding evidence pack that you reuse for every exit. When someone asks “What did you do with our data?”, you want to pull a complete bundle in minutes instead of chasing old emails and logs.

What should a standard offboarding evidence pack contain?

A simple three‑layer structure works well:

Top layer – rules and intent:
Information deletion / retention policy, including how “no longer required” is defined.
Retention schedule showing categories, retention periods and default end‑of‑life actions.
Roles and responsibilities for offboarding and deletion.

Middle layer – how you operationalise it:
Offboarding playbook and responsibility matrix.
Standard checklists or forms used during exits.
Internal guidance on deletion, anonymisation and handling exceptions such as legal holds.

Bottom layer – what happened for this client:
The PSA/ITSM offboarding record and related change tickets.
The agreed export list and client confirmation of receipt and usability.
Logs or reports from key systems (cloud, backup, SaaS, RMM, monitoring) that show deletion, expiry or access removal.
Any destruction certificates or written confirmations you issued.
A short closure note describing what was deleted, what was retained, why, and for how long.

Linking this pack to the client record in your ISMS makes it quick to retrieve and reuse. In ISMS.online, you can store these artefacts as evidence against A.8.10 and related controls, making internal and external audits far more straightforward.

How does this approach help beyond satisfying ISO 27001?

Standardised offboarding packs do more than satisfy A.8.10:

They reduce friction when former clients ask for assurance that their data is no longer in your environment.
They support renewals and referrals, because you can show that you handle exits as carefully as onboarding.
They give new team members clear examples to follow, so the ability to demonstrate good offboarding doesn’t depend on one or two long‑serving engineers.

Handled well, offboarding becomes a quiet selling point: you look like a provider that closes the loop properly, and you can prove it with live examples during security questionnaires, RFPs and due diligence.

Why does managing A.8.10 through an ISMS platform like ISMS.online make MSP offboarding easier to run and prove?

Managing A.8.10 through an ISMS platform simplifies offboarding because it connects policies, risks, assets, workflows and evidence in one place, instead of scattering them across documents, tickets and individual memory. Rather than relying on people to remember rules and logs, you can let the system guide and record the right actions.

How does an ISMS platform improve day‑to‑day control for A.8.10?

With a platform such as ISMS.online you can:

Link A.8.10 directly to relevant assets and data flows, so your map of where client information lives feeds straight into exit planning.
Attach retention rules and end‑of‑life actions to specific information types, so engineers can see inside the platform whether items should be deleted, anonymised or archived.
Build your offboarding workflow, RACI and checklists as live items inside the ISMS, with owners, review dates and change histories, not static files on a shared drive.
Capture tickets, approvals, logs and confirmations as evidence against the control, so everything you need for audits and client reassurance is already in one place.
Include A.8.10 in internal audits and management reviews, so you can spot gaps – for example, a system where deletions are not yet logged – and track improvements over time.

That turns deletion and offboarding into part of your normal compliance rhythm, rather than a side project you revisit only when certification renewals loom.

How does this change how you show up to customers and auditors?

When offboarding and deletion are visibly driven by your ISMS rather than improvised for each contract, you can:

Answer security questionnaires and RFPs with consistent, specific explanations of how you handle end‑of‑life for information, backed by real examples from your evidence packs.
Give auditors a clear line of sight from A.8.10 through to risks, assets, workflows and proof, reducing the time they spend testing your approach.
Reassure former clients that their data genuinely leaves once there is no legitimate basis to retain it, supported by artefacts you can retrieve quickly.

If you want your MSP to be recognised as a provider that handles exits as professionally as onboarding – and can demonstrate that under ISO 27001 A.8.10 – placing deletion and offboarding at the heart of your ISMS, with a platform like ISMS.online, is a practical way to achieve that and maintain it as you grow. It signals to customers, auditors and your own team that end‑of‑life handling is a core part of your service, not an afterthought.

A.8.10 Information Deletion – Secure Client Offboarding for MSPS