Forensic-Ready Evidence for MSPs: ISO 27001 A.5.28 Explained

From “just fix it” to “prove it”: why MSPs need forensic‑ready evidence

Forensic‑ready evidence means your MSP’s everyday tickets, logs and communications automatically form a clear, defensible record whenever an incident is questioned. Instead of saying “trust us, we did the right thing”, you can show who did what, when, with which approvals, on which systems, under which contract obligations.

In a dispute, the side with clearer records is often in a stronger position.

Forensic‑ready evidence turns your MSP’s day‑to‑day operational data into a storey that can withstand scrutiny from clients, insurers and regulators. When an incident is disputed, the side with clearer, more consistent records is usually in the stronger position, and that strength is built long before anything goes wrong.

Most managed service providers already sit on a mountain of operational data. Service tickets, remote monitoring and management (RMM) alerts, security information and event management (SIEM) events, email records and chat threads are created for almost every issue. Yet when a serious incident happens, leadership often discovers that this data does not add up to a coherent narrative. Timelines are incomplete, actions are undocumented, and key approvals live only in inboxes or chat tools.

A majority of organisations in the 2025 ISMS.online survey reported being impacted by at least one third-party or vendor-related security incident in the past year. For MSPs, that means your ability to evidence how you handled supplier and platform issues is now under much closer scrutiny than before.

That gap becomes painfully visible in three moments:

a key client disputes your version of an incident
a cyber insurer asks for detailed evidence before paying a claim
an auditor or regulator asks how you know you met your obligations

When you step back and look at those situations, you are not arguing about technology. You are arguing about facts, and the organisation that can produce a clear, contemporaneous record usually dictates the outcome of that conversation.

If your team has ever spent days reconstructing an event from scattered tickets, screenshots and exports, you have already felt the cost of weak evidential practice. Discounted invoices, strained relationships and uncomfortable conversations with boards often follow. Over time, these incidents erode margins and chip away at your reputation as a trusted provider.

Forensic readiness does not mean turning your MSP into a full digital forensics laboratory. It means designing your normal way of working so that, when you need evidence, it is already there: structured, traceable, trustworthy and proportionate. ISO 27001:2022 control A.5.28, “Collection of evidence”, formalises that expectation. Practitioner summaries of A.5.28, such as independent control explainers, emphasise planned, reliable identification, collection and preservation of evidence within an ISMS. It asks you to treat evidence as something you plan for, not something you scramble for.

When you think about your own organisation, a useful starting question is simple: if you had to brief a client’s legal team tomorrow on a critical incident from six months ago, could you rely on your existing tickets and logs alone, or would you be depending on people’s memories?

The hidden cost of weak incident records

Weak incident records quietly drain profit and trust, even when nobody calls them “evidence” yet. As an MSP leader, you feel this as increased write‑offs, longer escalations and more defensive conversations with customers and insurers after incidents.

Weak evidence rarely shows up as a line item in your profit and loss statement, but it steadily erodes profitability and confidence. Time spent reconstructing incidents is time not spent delivering value to customers, improving services or pursuing new business. Every “commercial gesture” made because neither party can prove their position eats into margins you thought were safe.

There is also an opportunity cost. Many MSPs promise “24×7 monitoring” and “proactive security” in bids, but cannot back those promises up with clean, auditable records. That makes it harder to win security‑sensitive customers in regulated sectors, or to justify premium pricing for higher‑assurance services. Prospective clients in financial, healthcare or public sectors increasingly ask “show me” rather than “tell me”.

The 2025 ISMS.online survey indicates that customers increasingly expect suppliers to align to formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials or SOC 2 rather than relying on generic “good practice”. That expectation raises the bar for MSPs that want to sell into regulated or security-conscious markets on the strength of their incident handling and evidential discipline.

Stronger incident records change those dynamics. When you can show a client a precise, well‑structured timeline and supporting evidence, difficult conversations become much easier. You can demonstrate due care, point to specific contractual boundaries, and show how decisions were agreed and executed. Insurers and auditors are also more willing to trust a provider who can quickly produce consistent records.

If you, as an owner or managing director, regularly agree write‑offs after incidents because the facts are unclear, that is a clear sign your evidential practices are costing you both profit and negotiating strength.

What forensic‑ready really means for an MSP

For an MSP, forensic readiness is the ability to reconstruct important incidents across all tenants quickly and convincingly, using evidence drawn from your everyday tools. It is less about specialist forensics kits and more about making your normal operations evidential by design, especially in a multi‑tenant environment where you sit between many customers and many vendors.

Around 41% of respondents in the 2025 ISMS.online survey said that managing third-party risk and tracking supplier compliance is a top information-security challenge. For MSPs, that reality makes it even more important that your tickets and logs can show exactly how you handled issues across cloud platforms, vendors and downstream tools.

Two ideas sit at its core. First, you decide in advance what kinds of evidence matter for the incidents you face most often: security breaches, business email compromise, outages, data‑loss events, access mistakes and so on. That means thinking through which tickets, logs, emails and approvals will be needed to answer the hard questions from clients, insurers or regulators.

Second, you design your tools and processes so that this evidence is generated, captured and preserved by default. Analysts do not need to remember complex rules in the heat of an incident; the service desk, monitoring stack and documentation platform guide them to capture what is needed. For example, a suspected compromise template might prompt for log references, approvals and customer notifications in a consistent way.

Seen this way, A.5.28 is not an abstract compliance requirement. It is a prompt to move from fix and forget to fix, record and be ready to prove it across every part of your MSP operation, including how you handle third‑party cloud platforms and shared‑responsibility boundaries.

A simple comparison makes the difference concrete:

Aspect	Ad‑hoc incident handling	Forensic‑ready incident handling
Tickets	Free‑text notes, inconsistent fields	Structured fields, consistent timelines, clear owners
Logs	Pulled when needed, scattered exports	Pre‑planned retention, known locations, referenced
Approvals & decisions	Buried in email or chat	Summarised in ticket, linked to named approvers
Third‑party platforms	Handled case by case	Clear rules on what is captured from each key system
Outcome in disputes	Reliant on memory and negotiation	Supported by documented actions and preserved artefacts

When you look at this side‑by‑side, the key contrast is simple: ad‑hoc handling leaves you arguing from memory, while forensic‑ready handling lets you point to evidence that speaks for itself. Forensic‑ready MSPs turn everyday operational data into a strategic asset rather than a fragile patchwork.

If you cannot pull a complete timeline for last quarters major incident within a day, that is a clear sign your forensic readiness and A.5.28 practices need attention.

Book a demo

What ISO 27001 A.5.28 “Collection of evidence” really asks for

A.5.28 expects your organisation to identify, collect and preserve information that could be used as evidence, in a planned and reliable way rather than on instinct. In practice, that means knowing when incidents deserve evidence‑grade handling, what you will capture from your MSP stack, and how those records will be protected so their integrity can be trusted later.

ISO 27001:2022 control A.5.28 requires you to have clear, documented ways to identify, collect, acquire and preserve information that could be used as evidence when security events or incidents occur. In plain terms, it expects you to think ahead: decide what might need to be used as proof, plan how you will capture it, and protect it so it remains trustworthy.

Because the official standard text is licenced, it is common for organisations to work from professional summaries and implementation guidance. Widely used Annex A explainers and A.5.28 control summaries help practitioners understand the intent of the control without reproducing the full standard.

Those, along with practitioner summaries, consistently highlight four expectations behind A.5.28:

you know when evidence‑grade handling is needed
you know what kind of information counts as evidence in your context
you know who is allowed to handle it and how they should do so
you can later show that evidence was collected and preserved properly

For MSPs, that means linking A.5.28 to the realities of multi‑tenant operations. Evidence may live in your professional services automation (PSA) tool, RMM, SIEM, identity platform, backup systems, email gateways and more. The control does not ask you to capture everything indefinitely. It asks you to be deliberate and consistent about what matters most and why.

If you cannot explain what counts as evidence in your environment and who is responsible for it, your A.5.28 implementation is not ready for scrutiny.

This information is general and does not constitute legal advice. For decisions about specific cases, contracts or regulatory obligations, you should consult appropriately qualified legal and compliance professionals.

For an MSP, the four A.5.28 verbs – identify, collect, acquire and preserve – translate into specific behaviours for your teams when they handle incidents. The more clearly you describe those behaviours, the easier it becomes to train, test and audit them.

When you translate A.5.28 into everyday language, four verbs stand out: identify, collect, acquire, preserve. Together they describe how you turn a messy incident into a defensible record instead of scattered notes and memories.

Identify: means recognising that a particular event, ticket or artefact has potential evidential value. For example, a suspicious mailbox rule, a failed privileged login, or a customer complaint about unexpected access may all be evidence sources.
Collect: covers the act of gathering relevant information while an incident is ongoing. That might be attaching log extracts to a ticket, saving a copy of a malicious email, or exporting a configuration snapshot before making changes.
Acquire: is often used in digital forensics for more formal capture, such as taking a forensic image of a server or exporting a large log set in a controlled way. MSPs may rely on specialist partners for this in high‑stakes cases.
Preserve: is about maintaining integrity over time. Once evidence is collected, it must be stored securely, with access controlled and changes tracked, so that you can later show it has not been altered inappropriately.

In practice, auditors will look for two things. First, that you have documented procedures explaining how these verbs apply in your environment. Second, that you can produce real examples: tickets, log archives, screenshots and reports showing these procedures were followed for actual incidents.

Where A.5.28 fits in the incident lifecycle

Evidence collection is one part of a wider incident lifecycle that runs from planning and detection through to learning and improvement. For MSPs, the lifecycle needs to work across many customers while respecting each client’s contracts and regulatory context.

Annex A control summaries show that, in the 2022 edition of ISO 27001, A.5.28 sits alongside controls that cover planning for incidents, handling them, learning from them and reporting them. Evidence collection is one part of that lifecycle and should be visible in each stage, not bolted on at the end as an afterthought.

Step 1 – Plan how incidents and evidence will be handled

You define how incidents are classified, who owns them at each stage, and who decides when evidence‑grade handling is required. This planning provides the structure that keeps people calm when incidents become stressful.

Step 2 – Detect and assess events against those plans

You detect and triage events, decide which ones are true incidents, and identify the ones that need enhanced documentation and evidence capture. Clear criteria help teams recognise the moment when a routine issue becomes a potential evidence case.

Step 3 – Respond while capturing key information

You take technical and business actions to contain and resolve the incident, while ensuring the ticket, logs and approvals are recorded as you go. Evidence needs to grow alongside the response, not be added in a rush afterwards.

Step 4 – Collect and preserve evidence properly

You gather and store relevant artefacts in line with A.5.28, using agreed locations and access controls so their integrity can later be defended. At this stage, you are turning operational data into an evidential asset that can stand up in a dispute.

Step 5 – Review incidents and improve your controls

You use the evidence record to analyse what happened, demonstrate due diligence and refine your controls, processes and contracts. Lessons learned sessions are far more effective when they are based on solid records rather than partial recollection.

For MSPs, the service desk ticket is often the central artefact that links these steps together. Designing that ticket to support A.5.28 is therefore one of the highest‑value changes you can make, because it gives every engineer a familiar place to record what matters.

If you cannot quickly show how a recent major incident moved through these five stages, it is unlikely your evidence collection will stand up well in a dispute or audit.

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

Translating A.5.28 into MSP forensic readiness

Forensic readiness for an MSP means being able to reconstruct important incidents across all tenants quickly and convincingly, using evidence drawn from your everyday tools and contracts. A.5.28 becomes the anchor that connects that capability to your ISO 27001 information security management system and to the promises you make in your service catalogue.

A good forensic‑readiness goal is specific and measurable. For example: “For any priority‑one security incident, we can produce a complete timeline, with supporting evidence, within twenty‑four hours of a request from a client, insurer or regulator.” That kind of statement gives you something concrete to design and test against, and it aligns with the expectations that many enterprise customers now bring to their MSPs. Guidance on digital forensic readiness for large organisations, such as independent consulting overviews, emphasises structured, evidential incident handling from service providers.

To reach that state, you need to align three layers:

your ISMS documents (policies, procedures, risk assessments)
your operational workflows (service desk, monitoring, change, communication)
your tool configuration (ticket fields, log retention, access rights, automation)

When those layers are connected, A.5.28 becomes much easier to demonstrate. Your policy describes what you will do, your workflows guide staff to do it, and your tools produce the evidence that shows it happened. A central ISMS platform such as ISMS.online can help you keep those layers synchronised by mapping your policies and procedures directly to Annex A controls and linking them to real incidents. This pattern of using a central ISMS or incident‑response platform to connect policies, controls and incident records is widely reflected in security incident response platform guidance.

Forensic readiness turns A.5.28 from a compliance obligation into a commercial asset that supports both trust and negotiation strength.

Setting concrete forensic readiness objectives

Forensic readiness objectives should give you a clear target for the quality and speed of your incident evidence, tailored to your customer base and risk profile. Without them, it is hard to judge whether your current practices are good enough or just “good enough until something serious happens”.

As an MSP leader, you need forensic readiness objectives that reflect both your risk profile and your customer mix. Objectives for a small business‑only portfolio will differ from those for financial or healthcare customers who face regulatory scrutiny and litigation risk.

You might start by asking:

for which clients or service lines would an evidential failure hurt you most?
which incident types create the highest risk of disputes or regulatory scrutiny?
how quickly do customers, insurers or regulators expect answers in practice?

From there, you can define a small number of objectives, such as:

“All critical security incidents have a complete, time‑stamped action log in the ticket.”
“For defined incident types, we retain key logs for at least twelve months.”
“High‑risk incidents include a simple chain‑of‑custody record for exported artefacts.”

Those objectives then flow into control design. They influence which fields are mandatory in tickets, which logs are centralised, how long data is kept, and which cases require extra handling. They also give you a benchmark when customers ask, “How do you prove what happened?” or “How quickly can you show us the detail?”

Embedding A.5.28 in your ISMS

Embedding A.5.28 in your ISMS means weaving evidence expectations into policies, risk assessments, procedures and reviews, rather than treating them as a separate checklist. Done well, this gives auditors and customers a clear line of sight from written intent to real incident records.

Once you know what you want forensic readiness to achieve, you can weave A.5.28 through your ISMS in a structured way, rather than treating it as a stand‑alone control.

Typical steps include:

updating your incident‑management procedure so it references evidence identification, collection and preservation explicitly
creating a dedicated evidence‑collection procedure that explains roles, triggers and steps for different incident types and client profiles
ensuring your risk assessment considers evidential risks, such as incomplete logging or unclear responsibilities with cloud providers
adding evidence‑related controls and monitoring activities to your internal audit and management review plans

A platform such as ISMS.online can help by giving you a single place to hold these policies, map them to Annex A controls, assign responsibilities and track improvements. Many ISO 27001‑aligned cloud and compliance platforms are designed to centralise policies, control mappings and evidence in this way (for example, cloud providers’ ISO 27001 overviews describe similar patterns).

Over time, you should be able to pick any significant incident from the past year and show how A.5.28 was satisfied: who recognised the evidential need, what was collected, where it is stored, and how its integrity is protected. You can also extend this approach to new frameworks, such as ISO 27701 for privacy or emerging guidance for AI governance, without reinventing your evidential logic each time.

Designing a forensic‑ready service desk and ticket model

A forensic‑ready service desk lets your engineers handle incidents at speed while still creating records that support A.5.28 and your contracts. The goal is to shift effort from memory and manual discipline into templates, automation and guardrails in your PSA or IT service management platform.

At a high level, you want your ticketing platform to support three things for evidence‑sensitive work:

triggering: enhanced documentation when a case is evidence‑sensitive
capturing: the right information consistently, with helpful defaults
protecting: the record against uncontrolled changes once it matters

You do not need to rebuild your PSA or IT service management tool from scratch. Thoughtful configuration and a few targeted workflow changes can make a substantial difference, especially if you test them against real incidents you have handled in the past year.

When incident records are shaped by the system rather than by individual habits, you move much closer to repeatable, audit‑ready evidence.

Triggering evidence‑sensitive handling

Triggering evidence‑sensitive handling is about giving frontline engineers simple rules and clear visual cues so they know when a routine ticket has become a case that may be scrutinised months later. Without those triggers, important incidents are documented like trivial ones.

Not every ticket requires forensic‑grade attention. Forensic readiness is about being selective and consistent. You can start by defining which types of tickets should automatically be treated as evidence‑sensitive. These might include:

confirmed or suspected security incidents
data‑loss or data‑exposure events
major outages affecting many users or critical services
complaints that may lead to formal disputes or regulatory reporting

When such a ticket is created or re‑categorised, your system can:

apply a specific template with additional mandatory fields
route it into a dedicated queue with more senior oversight
enforce stronger rules about who may edit core fields
prompt the handler to attach or link specific artefacts, such as log searches or email headers

By turning evidence sensitivity into a property the system recognises, you reduce the risk that important cases are documented like ordinary password resets. You also create a clear signal for managers and security leads to monitor and support those cases as they unfold.

If your security lead cannot easily list which open tickets are evidence‑sensitive today, your triggers and classifications are probably too vague.

Designing workflows that support investigations, not just SLAs

Workflows that support investigations keep a clean, factual trail of actions and decisions, while still allowing engineers to resolve issues quickly. They make it easy to see what happened, when and why, without reading pages of unstructured notes.

Traditional service desk workflows focus on restoring service as quickly as possible. That remains important. However, when you care about evidence as well, you need the workflow to support later investigation work and show you have met your obligations to customers and regulators.

Useful patterns include:

ensuring every status change and assignment is logged with timestamps and user identities
requiring a short summary of key actions when certain statuses are reached, such as “contained”, “resolved” or “handed to legal”
locking or limiting edits to critical fields once a case passes a defined point, while still allowing additional notes and attachments
providing macros or templates for common investigations (for example, “suspected phishing” or “unauthorised access”) that guide analysts through the right steps and questions

It is also important to think about communications. If key decisions and approvals are happening in chat tools, phone calls or side channels, the workflow should include a simple way to summarise or capture those into the ticket while events are fresh. Otherwise, valuable context will be missing when you need it most or when a client’s legal team asks for a full account.

Once workflows make investigations easier rather than harder, engineers are far more likely to create the records you need without seeing them as a burden.

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

Book your demo

What to capture: ticket fields, logs and attachments as evidence

Evidence‑ready incident records are built on consistent, structured information that can be understood by people who were not in the room at the time. As an MSP operations or security lead, you want tickets that someone else can pick up months later and still follow the storey clearly, supported by referenced artefacts rather than scattered files.

The aim is not to create a long, painful form for every ticket. It is to decide which details are non‑negotiable for specific scenarios, and to make capturing them as easy as possible for your teams through templates, defaults and prompts.

Structuring high‑value incident tickets

High‑value incident tickets should answer essential questions about who was involved, what happened and how you responded, without relying on memory or guesswork. If a new engineer or an external reviewer cannot follow the storey, your structure needs work.

For evidence‑sensitive incidents, certain questions must always be answerable from the ticket alone. At minimum, that usually includes:

who reported the issue and when
when the issue was first observed and by whom
which client and which systems or services were affected
what the impact was at the time of detection
who took which actions, in what order, using which tools
who approved major decisions, such as disabling controls or notifying customers
when the incident was contained and closed, and why you believed it was safe to do so

Many of these can be captured in structured fields: reporter, affected customer, impacted systems (linked to configuration items), incident type, severity, timestamps and so on. Others can be captured in short, focused text fields such as “summary of investigative actions” or “summary of client communications”.

Standardising these elements has clear benefits. It reduces the burden on individuals to remember what to record, gives reviewers a consistent layout to work with, and makes it easier to extract data for audits, metrics and improvements. It also makes training simpler: you can show new engineers what “good” looks like by walking through well‑structured example tickets.

Connecting tickets to technical artefacts

Connecting tickets to technical artefacts means you always know where to find the underlying logs, screenshots and configuration snapshots that support your narrative. Tickets tell the storey; artefacts supply the proof that sits behind the words.

Tickets are the narrative spine of your incident record, but they are not the only evidence. Logs, screenshots, configuration snapshots, message traces and other artefacts provide the technical detail that underpins the storey and may be needed to satisfy insurers or regulators.

A practical approach is to define, for each incident type, a minimum set of artefacts that should be referenced or attached. For example, a suspected account compromise might always include:

authentication logs for the affected account over a defined window
administrative action logs showing password resets or access changes
email gateway or mailbox logs for suspicious messages
endpoint or detection‑and‑response alerts relating to the device used

Rather than dumping raw data into the ticket, you can store canonical versions in your logging or document systems and reference them clearly from the incident record. That might be done via identifiers, folder paths or a short description of where they can be found and under what name.

For files that are attached directly to tickets, simple measures like noting original filenames, keeping versions, and limiting who can delete or replace attachments all contribute to later confidence that the evidence has not been quietly altered. For the highest‑risk cases, generating and storing hashes or checksums for key files is a proportionate way to strengthen the evidential storey without over‑engineering every ticket.

If your security lead cannot quickly point to the log set and artefacts that back a major incident ticket, your linkage between narrative and technical evidence needs attention.

Log retention, preservation and chain of custody for MSPs

For MSPs, log retention and evidence preservation need to balance investigative usefulness, privacy obligations and storage costs across many customers and jurisdictions. You cannot keep everything forever, but you also cannot explain an incident months later if crucial records were overwritten after a few days.

Logs and other machine‑generated records often form the backbone of digital evidence. For MSPs, those records may originate in many different systems and jurisdictions. A.5.28 expects you to handle them in a way that supports investigations while respecting legal and contractual boundaries.

A useful way to approach this is to ask four questions:

which logs and artefacts do you genuinely need for investigations?
how long do you need to keep them, and why?
how will you protect them against unauthorised change or loss?
how will you document who has handled high‑risk evidence and when?

Clear answers to those questions turn a vague “we keep logs” into a defensible log‑retention and evidence‑preservation strategy that can be explained to clients, auditors and regulators. Log data that is missing or cannot be defended under scrutiny does not help you; it undermines you.

Designing log retention that actually supports investigations

Effective log retention policies start from real incident scenarios and regulatory expectations, not from default tool settings or vague comfort levels. If the logs you delete next week could be the ones you need in three months, your retention design is not aligned with your risk.

Default retention periods in tools may not be designed with your specific risk profile in mind. Logging and security analytics guidance typically recommends aligning retention to your investigative and regulatory needs rather than relying solely on vendor defaults; logging best practice overviews underline this point.

A more deliberate approach starts with incident scenarios and obligations. For example:

if you have to investigate suspected malicious activity weeks after it occurred, you will need longer retention for identity and access logs
if contracts or regulations require you to notify authorities or customers about incidents, you may need logs to reconstruct events months later
if privacy laws limit how long certain personal data can be held, you may need to aggregate or anonymise some information earlier

Based on those factors, you can define retention baselines for each log category, with justified exceptions where needed. Those baselines should be reflected in your ISMS documentation, your tooling configurations and your communications with clients. They may differ between clients in different countries, so you need a clear record of which retention rules apply where.

Centralising logs, or at least centralising knowledge of where authoritative logs live, also matters. When evidence is spread across firewalls, servers, cloud services and endpoints without an organising structure, it becomes much harder to answer even basic questions about who accessed what and when. Security operations guidance for SIEM and analytics platforms encourages the use of central log platforms or clearly documented log maps to cut investigation time and reduce the risk of missing crucial data, as illustrated in SIEM and security analytics platform overviews.

Making chain of custody simple enough to follow

Chain of custody is the record of how evidence has been collected, stored, accessed and transferred over time. In formal digital forensics, this can be highly detailed. For MSPs, you usually need a simpler version that can still withstand reasonable scrutiny in a dispute or audit.

The key is to focus on high‑stakes artefacts: those that are likely to be used in disputes, regulatory investigations or legal processes. For those, you should be able to show:

who decided the evidence should be collected
who actually collected or exported it, and when
where it was stored initially and where it is now
who had access along the way

You do not need a separate system to achieve this. A common pattern is to record custody information in the incident ticket itself for major exports, and to ensure your storage systems keep basic audit trails of access and changes.

The most important property of a chain‑of‑custody record is that it is maintained consistently when it matters. If the process is overly complex, engineers will skip it under pressure. Keeping it as lightweight as possible, backed by clear guidance on when it applies, is the best way to ensure it is actually followed. Periodic reviews of a small sample of high‑risk incidents will quickly show whether the approach is working.

If your security practitioners cannot explain who exported key evidence for a recent high‑profile incident and where it now resides, your current chain‑of‑custody approach is probably too informal.

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

Book your demo

Governing evidence: policies, roles, training and legal alignment

Forensic readiness is not only a tooling problem. It is a governance problem. As an MSP leadership team, you set the tone on how evidence is handled by defining policies, roles and oversight that make good practice the default rather than a heroic effort during crises.

A.5.28 lives in the organisational control set for a reason. It expects leadership to take responsibility for how evidence is handled. That means aligning security, legal, privacy and operations, not leaving evidence decisions solely to individual engineers in the moment.

Building an evidence‑aware policy stack

An evidence‑aware MSP has a small number of policies and procedures that work together rather than against each other. These documents are short enough to be used, clear enough to avoid contradictions, and specific enough to guide the frontline.

Two-thirds of organisations in the 2025 ISMS.online survey said the speed and volume of regulatory change are making compliance harder to sustain. That reality makes it even more important that your incident, evidence and privacy policies are aligned, so busy teams are not left guessing how to reconcile conflicting obligations during a crisis.

Typically, you will want at least:

an incident‑management policy and procedure that sets out how incidents are identified, triaged, handled and reviewed
an evidence‑collection and preservation procedure that explains how A.5.28 is applied in different scenarios
privacy and data‑retention policies that set limits on what can be collected, how it is protected and when it must be deleted or anonymised

These documents should cross‑reference one another. For example, the incident procedure might state that certain incident types automatically invoke the evidence procedure. The evidence procedure might explicitly reference privacy rules, client contracts and escalation criteria to legal or data protection officers so you do not collect or retain more personal data than necessary.

When policies are aligned in this way, staff have clear, non‑conflicting guidance. When they are not, teams are forced to improvise during stressful events, which is when mistakes and oversights are most likely. An ISMS platform such as ISMS.online can help you maintain that alignment by linking policies to controls, incidents and improvement actions in one place. Many ISO 27001‑aligned cloud and compliance platforms are designed to support similar centralisation and mapping patterns, as described in providers’ ISO 27001 compliance overviews.

Raising skills and oversight

Raising evidence skills and oversight means giving engineers simple, practical guidance on what “good” looks like, then checking real incidents against that standard. You want evidence handling to feel like part of good engineering, not a separate compliance chore.

Even the best‑designed procedures will fail if people do not understand them or cannot apply them. Training and oversight close that gap. You want engineers and managers to see evidence handling as part of good service, not an optional extra.

Frontline analysts and service desk staff do not need to become forensic experts. They do, however, need to recognise when a routine ticket becomes evidence‑sensitive, and to know a handful of clear do’s and don’ts. For example:

do keep tickets factual and focused on actions and observations
do capture key approvals and decisions in the record
do avoid speculation and blame in the evidential trail
do not alter or delete evidence once it has been marked as such without following defined steps

Short, scenario‑based training built into onboarding and refreshed periodically is usually more effective than long, theory‑heavy sessions. You can use real incidents (with details anonymised where needed) to show what “good” and “poor” evidence look like.

On the oversight side, you can embed evidence quality into existing structures rather than creating entirely new ones. Risk or security committees can periodically review a small sample of significant incidents with an eye on evidence completeness and clarity. Internal audits can include tests of A.5.28, using real tickets and logs as samples and tracking findings through to closure.

A central ISMS platform such as ISMS.online can help by providing a home for these policies, recording that key staff have been trained, and tracking actions arising from reviews. This mirrors the capabilities described for other security and incident‑management platforms, which centralise policies, training records and corrective actions (for example, security incident response platforms). That way, evidence governance becomes part of your normal management rhythm, not an occasional, isolated exercise. It also makes it easier to show customers, auditors and insurers that you manage evidence systematically rather than informally.

If your leadership team has never looked at a real high‑risk ticket with “evidence quality” in mind, building that review into your governance rhythm is a simple, high‑impact next step.

Turning A.5.28 into a repeatable strength with ISMS.online

ISMS.online is designed to help your MSP turn ISO 27001 control A.5.28 into a repeatable strength by joining your policies, tickets and logs into one coherent evidence storey. When you can show how incidents are handled, how evidence is collected and how improvements are tracked, you strengthen both your compliance posture and your commercial relationships. That approach follows the general pattern of ISO 27001‑aligned platforms that connect policies, controls and incident artefacts in a single system of record, as reflected in security incident and compliance tooling guidance.

Almost all organisations in the 2025 ISMS.online survey listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority. If you can link A.5.28 directly to the way you evidence incidents, you are much better placed to sustain those certifications under real-world scrutiny.

If you want to understand where you stand today, a useful first step is to take one significant recent incident and compare its tickets, logs and communications against a simple A.5.28 checklist. You will quickly see which details were easy to find, which required detective work, and which were missing entirely. That exercise makes the benefits of a more structured approach immediately tangible for both leadership and engineers.

Assessing your current evidence maturity

Assessing your current evidence maturity starts with one honest look at a real, high‑risk incident. Instead of guessing how good your records are, you let a single case show you the truth.

You can pick a major incident from the last year and ask four straightforward questions. Could you see the full timeline from detection to closure? Could you find the key approvals and decisions? Were the logs and artefacts easy to locate and understand? Would you be comfortable sharing that record with a client’s legal team or an insurer?

If the answer to any of those questions is “not really”, the gap is already clear. That does not mean your team performed badly; it means your system did not support them with the evidential guardrails they needed in the moment.

ISMS.online can help you document these findings and link them directly to the A.5.28 control, so weaknesses become tracked improvement actions rather than vague concerns people quickly forget.

Planning your first A.5.28 improvements with ISMS.online

Planning your first A.5.28 improvements is easier when you can see policies, controls and real incidents in one place. ISMS.online gives you that view and turns it into a practical improvement plan rather than a theoretical wish list.

In ISMS.online you can:

maintain your incident and evidence‑collection procedures in a controlled, auditable way
link those procedures directly to Annex A controls, including A.5.28 and related incident‑management controls
record real incidents, improvements and internal audit findings against those controls
assign actions and track progress on closing evidential gaps across teams and clients

Because ISMS.online is designed to sit alongside, not replace, your PSA, RMM and security tools, it can act as the connective tissue that turns operational records into a coherent evidence system. Your tickets, logs and artefacts remain where they belong; the platform helps you show how they fit together and how they are governed, which is exactly what auditors, clients and insurers want to see.

In many cases, a focused implementation over a few months is enough to establish a baseline forensic‑ready posture for your most important clients and incident types. Forensic‑readiness programmes described in independent consulting guidance are often structured as time‑bound projects rather than open‑ended initiatives, which is a useful pattern to emulate.

That baseline typically includes getting your policies aligned, templates agreed, basic chain‑of‑custody practices in place and reviews running. Once the foundations are there, extending the approach across your wider customer base becomes much easier and less disruptive.

If you are ready to move from hoping your records are good enough to knowing you can evidence what happened, choosing ISMS.online as your ISO 27001 companion is a practical next step. You reinforce your ability to protect your business, your customers and your teams when incidents are scrutinised most closely, and you turn A.5.28 into a reliable source of confidence rather than a source of anxiety.

Book a demo

Frequently Asked Questions

What does ISO 27001:2022 A.5.28 “Collection of evidence” actually change for an MSP?

A.5.28 means your MSP must be able to prove what happened in serious incidents, not just remember it later.

In practice, that changes your day‑to‑day in four areas:

When does normal incident handling become “evidence‑sensitive”?

You need a clear, agreed line between routine support noise and cases that demand an “evidence‑grade” response. Typical triggers include:

Suspected data leak or exfiltration for any managed customer.
Business email compromise or account takeover.
High‑impact outage with contractual or financial impact.
Fraud attempts, abuse of privileged access, or insider misuse.
Any incident likely to interest regulators, insurers or lawyers.

Once a trigger is hit, the incident is treated differently: tighter logging, stronger access control, and more deliberate handling of artefacts.

Who is accountable for evidence decisions in your MSP?

A.5.28 expects you to know who can declare an incident evidence‑sensitive and who can touch the trail afterwards. That usually means:

A named duty role (e.g. Duty Manager, on‑call Security Lead) empowered to flip an incident into evidence‑sensitive mode.
Clear responsibilities for:
Deciding which artefacts must be collected.
Approving destructive actions (rebuilds, wiping, tenant resets).
Signing off when evidence handling for that incident is complete.

These roles should be visible in your ISMS, job descriptions and incident procedures – not just “understood” by the team.

What does “good enough for evidence” mean in MSP reality?

You are not standing up a police lab. You are aiming for incident records that an external party can trust, because:

The storey is coherent: what happened, when, to whom, and on which systems is clear.
Key decisions and approvals are captured in the record, not buried in chat.
Artefacts (logs, exports, screenshots) can be located and tied back to the incident.
You can show that sensitive exports have not been quietly edited.

That typically looks like:

Evidence‑sensitive flags in your PSA/ITSM.
Minimum evidence packs per scenario (e.g. BEC, outage, suspicious admin activity).
Controlled locations for exports with restricted access and basic integrity measures.

How does an ISMS platform change your A.5.28 storey?

If you try to manage A.5.28 only in your PSA and people’s heads, it quickly unravels under scrutiny. An ISMS platform like ISMS.online lets you:

Document your A.5.28 policy and procedure once, in plain language.
Link it directly to incident management, logging and continuity controls.
Attach real incidents as evidence of operation over time.
Track improvements when reviews find gaps.

That turns A.5.28 from “we think we handle evidence sensibly” into “we can show you how we decide, collect, protect and improve” – a very different conversation with auditors, customers and insurers.

How can an MSP make its service desk “forensic‑ready” without slowing engineers down?

Your service desk is forensic‑ready when high‑risk tickets automatically become structured incident stories, while everyday work still feels light and fast for engineers.

The aim is not more admin on every ticket. It is smarter behaviour only when the stakes are high.

How should tickets behave once a case is evidence‑sensitive?

Three design tweaks do most of the work: classification, structure and protection.

Classification – flip mode with one clear signal

Build a small set of categories or flags that automatically treat a ticket as evidence‑sensitive, such as:

Security incident or suspected breach.
Data exposure or privacy‑relevant event.
Major outage affecting SLAs or multiple customers.
Complaints that might escalate to legal or regulatory action.

When these are chosen, the system can:

Enforce additional fields and attachments.
Restrict edits to core fields.
Trigger notifications to duty roles.

Structure – turn notes into a usable incident narrative

For flagged tickets, require:

Mandatory core fields (customer, impacted systems, severity, detection time, owner, incident type).
A dedicated timeline section:
Time (with zone).
Action taken.
Tool or system used.
Reference IDs (alert, change, export or case numbers).
Attachments or links for required artefacts per scenario before closure (e.g. sign‑in logs for BEC; change records and monitoring graphs for outages).

This makes the ticket the “front page” of the incident storey, with links out to heavy data instead of trying to cram everything into one record.

Protection – stop history being quietly rewritten

You do not want key timestamps and approvals changing days later. A balanced approach is:

Locking or versioning critical fields after a defined window or once an approval is recorded.
Allowing new comments and files to be added freely.
Recording who authorised any correction to core details.

The usability test is simple: could someone who was not involved reopen the ticket six months later and understand what happened and who decided what in under ten minutes?

How does this connect back to A.5.28 and your ISMS?

A.5.28 is not really about your tool; it is about your intentional design:

Your ISMS holds the policy for when tickets switch modes, what changes in that mode, and which roles are involved.
Your service desk executes those rules quietly in the background.
Reviews in your ISMS sample real tickets, record findings, and drive template changes or extra training.

ISMS.online is built for exactly that loop: design → operate → review → improve. If you are trying to answer A.5.28 using only screenshots and “we usually do X”, you will feel constantly on the back foot. A few days of configuring your PSA and capturing the governance in ISMS.online puts you in a position to show auditors that this behaviour is deliberate, repeatable and monitored.

Which incident details and artefacts actually make MSP evidence reliable?

Evidence is reliable when it answers obvious questions without you needing to be in the room:

What happened and how was it detected?
Which customer and systems were involved?
Who did what, using which tools, and who authorised it?
What changed as a result, and when?

Dumping raw logs rarely achieves that. A small amount of structure and a consistent minimum pack per scenario usually does.

What should every high‑impact incident record include at minimum?

For incidents that touch money, contracts or data protection, your default pattern should cover three layers.

1. Structured ticket fields

Set these as mandatory once a ticket is flagged as higher risk:

Reporter and detection time.
Customer, primary contact and any contractual identifiers (e.g. contract ID, SLA tier).
Impacted systems or services (ideally selected from your CMDB or service catalogue).
Severity level and a one‑sentence impact summary.
Incident type (e.g. BEC, ransomware, P1 multi‑tenant outage).
Assigned owner and escalation contact.

This keeps every serious case aligned to the same mental model.

2. Action timeline

Move away from a single scrolling note field towards a simple, structured log:

Time and time zone.
Action taken.
Tool or system used.
Reference ID (alert ID, change ticket, export reference).

That timeline often becomes the backbone of later customer briefings, insurer claims or regulator reports.

3. Artefact pointers

Rather than bloating tickets, point to where heavy data lives:

Identity and access logs from your directory, SSO or VPN.
Endpoint and server alerts (EDR/AV/HIDS).
Email gateway or SaaS mail logs for phishing and BEC cases.
Firewall and network captures for outages or lateral movement.
Configuration snapshots and change records before/after key interventions.
Sanitised copies of malicious payloads or suspicious emails.
Screenshots where exports are not available.

A short pattern like “EDR logs for host X, 09:00–12:00 2024‑07‑03, stored in Vault V‑0123; checksum XYZ” turns a vague note into something a third party can trust.

For a few high‑risk scenarios, agree a minimum evidence pack (usually no more than 8–12 items) and build that into your PSA workflows. That stops serious tickets decaying into vague chat transcripts and makes it much easier to stand behind your work months later.

How can you prove this to auditors and customers?

Writing the pattern down is only half the job. A.5.28 expects you to show it working. With ISMS.online you can:

Link minimum evidence packs to A.5.28 and related Annex A controls.
Attach example incidents that meet (and fail) the pattern.
Track improvement actions when you spot recurring gaps.

So instead of saying “we aim to gather logs”, you can open your ISMS, walk through the pattern, and show concrete examples. That is the difference between a policy and a credible storey – and customers notice it when choosing which MSP to trust with their most sensitive systems.

How should MSPs handle log retention and chain of custody so evidence still holds up later?

Log retention and chain of custody are about being able to look back far enough, and being able to show you did not quietly alter the record.

If you treat logs as disposable or exports as casual files, A.5.28 will be hard to evidence and hard to trust.

How do you decide what to keep and how to protect it?

A practical approach for MSPs is to think in three passes.

1. Group logs by how you use them

For example:

Identity and access: directory, SSO, VPN, privileged access gateways.
Endpoint and server security: EDR, AV, HIDS.
Email and collaboration: secure email gateways, SaaS mail platforms, chat tools.
Network and perimeter: firewalls, proxies, VPN concentrators.
Administrative and change activity: cloud admin logs, CI/CD pipelines, infrastructure‑as‑code tools.

Each group supports slightly different questions during investigations and audits.

2. Set retention baselines per group

Balance three constraints:

Operational need: how far back you normally investigate (e.g. dwell times, fraud patterns).
Customer commitments: what your contracts and SLAs say about investigation support.
Regulatory privacy rules: where you must minimise personal data retention (e.g. GDPR, CCPA).

For many security‑sensitive MSP environments, 6–12 months for identity, email, endpoint and admin logs is a reasonable starting point, with some outliers needing longer. Whatever you choose, capture it in policy and configure your SIEM, log store and backups to enforce it, rather than relying on memory.

3. Add simple integrity and access controls

You do not need enterprise‑grade WORM across everything from day one, but you should:

Limit who can view and export sensitive logs.
Prefer append‑only or write‑once storage for long‑term archives.
Use checksums or signatures for bulk exports and archives.
Record who exported significant bundles, when, from where, and where they are now stored.

A short annotation like “M. Patel exported identity logs for tenant ACME from 2024‑06‑15 00:00–23:59, stored S3 bucket ‘evidence‑2024‑06‑ACME’; access: SOC leads only” can be enough to show a reviewer that you treat chain of custody seriously.

Where does an ISMS fit into this?

Scattered notes and undocumented retention choices are hard to defend. An ISMS platform such as ISMS.online lets you:

Document your log families, retention baselines and exceptions once.
Link them to ISO 27001:2022 A.5.28, related logging controls in Annex A, and any Annex L frameworks you run (e.g. ISO 22301 for continuity).
Attach real export examples and review notes as evidence.
Track when retention rules or tooling change, so you can explain the history.

That way, if a customer, auditor or regulator asks why you still have (or no longer have) certain logs, you can respond with a clear, policy‑backed answer instead of an uncomfortable shrug.

How can MSP teams build “evidence‑ready” habits without turning everyone into forensics specialists?

You do not need every engineer to understand case law. You do need them to leave behind tickets and log references they would be happy to defend under pressure.

If you make this about blame or compliance jargon, engagement will be low. If you make it about avoiding future pain for them and for customers, it becomes a lot easier.

What does practical, engineer‑friendly evidence training look like?

Short, specific sessions built around your own incidents work best:

Show the pain.: Bring an anonymised incident where poor records hurt you – unclear impact, confused timelines, missing approvals. Ask the team what made it hard to manage or explain.
Show the contrast.: Compare it with a better‑documented incident. Which one would they rather push in front of a sceptical customer, insurer or regulator?
Agree a small set of habits.: For example:
Always note what you did, when and in which tool, using clear time markers.
Capture key customer decisions and internal approvals in the ticket, not only in chat.
Keep comments factual; avoid blame or speculation in permanent records.
Use the evidence‑sensitive flag or category when defined triggers fire.

You can reinforce this by baking micro‑prompts into your PSA forms:

Next to the timeline field: “Write this so a colleague can understand it in six months.”
Next to attachments: “Link to log locations; avoid pasting huge extracts.”

Back this up with light, regular feedback:

Sample a small number of higher‑risk tickets each month.
Score them against your agreed habits and minimum evidence packs.
Share targeted feedback and highlight good examples in team meetings.

How can you prove that these habits are real, not just slides?

A.5.28 is not satisfied by “we run annual training”. You will be asked how you know it is working. ISMS.online helps you answer that by:

Storing the A.5.28 procedure, training artefacts and attendance records.
Linking recurring findings from ticket sampling into your incident and logging controls.
Tracking assigned actions (changes to templates, refinements to triggers or log retention, additional training) through to closure.

That gives you a live record of evidence‑readiness evolving in response to real incidents and reviews. When someone asks “how do you make sure staff handle evidence properly?”, you can point to patterns, not promises – and that is exactly what serious customers and auditors are looking for.

What can an MSP realistically improve around A.5.28 and forensic readiness in the next 90 days?

In 90 days you can move from “we hope our records are good enough” to “we have a clear pattern, documented in our ISMS, and recent incidents that demonstrate it”.

You do not need perfect coverage; you need a small number of visible, repeatable improvements backed by real examples.

What does a focused 90‑day A.5.28 improvement cycle look like?

A realistic roadmap could run like this:

Weeks 1–2: Learn from one serious past incident

Pick a case that mattered – a security incident or outage that reached senior stakeholders.
Review the ticket, logs and email trails as if you were an external reviewer.
Note:
How long it takes to understand what happened.
Where the storey is unclear or incomplete.
Which artefacts were missing or hard to find.
Capture this in a brief post‑incident note and log it against A.5.28 in your ISMS.

Select 2–3 scenarios that regularly worry your customers:
Business email compromise or account takeover.
Suspicious privileged activity in cloud platforms.
Major multi‑tenant outage.
For each, define:
Mandatory ticket fields.
Required artefacts (logs, exports, snapshots) and where they will live.
Update PSA templates and workflows so the right fields and attachments become non‑optional when relevant categories or flags are chosen.

Weeks 4–6: Document a concise procedure for A.5.28

Write a lean procedure that explains:
When an incident becomes evidence‑sensitive.
Which roles declare that and who is accountable.
What must be collected, where it is stored, how long it is kept.
How significant exports are tracked for chain of custody.
Map this directly to ISO 27001:2022 A.5.28, along with related Annex A controls for incident response, logging and, if relevant, business continuity.

Weeks 6–8: Train the people who will actually use it

Run a short session for engineers, duty managers and service desk leads using:
The reviewed incident (to show the pain of weak records).
Updated ticket templates (to show what has changed).
Minimum evidence packs (to clarify expectations).
Focus on what changes for them in practice and how this protects them in future customer or insurer conversations.

Weeks 8–12: Sample new incidents and show progress

A few weeks after rollout, sample a handful of incidents that should have triggered the new patterns.
Check:
Whether the correct triggers and flags were used.
Whether minimum evidence packs were captured.
How quickly someone uninvolved can understand each case.
Record findings and use them to:
Tweak templates and hints.
Target any follow‑up training.
Update your A.5.28 procedure if needed.

ISMS.online can anchor every step of this cycle:

The A.5.28 procedure, initial incident review, defined evidence packs, training material and sampling results all live in one environment.
Improvement actions gain owners, due dates and completion proof.
Links to Annex A controls and other standards (such as A.5.24–A.5.27 for incident management, A.8.x logging controls, ISO 22301 for continuity in an Annex L‑style IMS) show how evidence handling fits into your wider system.

So when a prospect, auditor or insurer asks, “How do you collect and protect evidence?”, you can walk them through a clear 90‑day storey where policy, tooling and real incidents line up. That is the kind of grounded answer that strengthens your ISO 27001 position, reassures higher‑value customers and quietly differentiates your MSP from competitors who still rely on improvised incident notes and good intentions.

A.5.28 Collection of Evidence – MSP Forensic Readiness & Ticket Evidence