ISO 27001 A.8.28: How to Build Trustworthy Incident Evidence for Regulators

When your biggest incident risk is missing evidence

Your biggest incident risk is often not the attack itself but the missing evidence when regulators, customers and the board demand answers. ISO 27001 A.8.28 exists to stop that by treating incident evidence as something you define, collect and preserve on purpose, so you can tell a clear, defensible storey about what happened, how you responded and why others should trust your account.

When a high‑impact incident lands, people often scramble across SIEM dashboards, cloud consoles, ticketing tools and inboxes trying to reconstruct events. Timelines are partial, screenshots are scattered and key decisions live only in chat threads. Regulators, customers and senior leadership, however, expect clear answers: what happened, when, to whom, how you know and what you did about it. If you lead compliance or operations without a deep security background, this is exactly the moment you fear being caught short.

Calm, structured evidence turns a crisis from guesswork into a storey you can stand behind.

A useful first step is to baseline your current reality. Look back at the last handful of significant incidents and ask a few blunt questions: were key logs missing or overwritten; could you show exactly who accessed which artefacts and when; did legal or privacy teams complain that they “could not prove” what was claimed in notifications or post‑incident reports?

From there you can develop a simple “evidence‑by‑design” storyboard for a typical serious incident. Start at first detection, move through triage, containment and recovery, and end with regulatory, contractual and customer communications. At each stage, mark what evidence exists today, where it lives, who owns it and where the chain currently breaks. That single, visual storey becomes a powerful alignment tool for CISOs, SecOps, compliance and legal.

As you refine that picture, widen the lens beyond pure technical telemetry. Evidence that matters in regulator‑reportable situations includes decisions (who decided what, when and on what basis), notifications sent, customer communications, third‑party correspondence and incident review outputs. Deciding and documenting which of these you will treat as “incident evidence” is the foundation for everything that follows.

If you are new to ISO 27001, it is enough at first to define a handful of high‑risk incident types and agree what “good enough” evidence looks like for each. You can then deepen and formalise that approach as your information security management system (ISMS) matures.

Why “we have logs” is not the same as “we have evidence”

Saying “we have logs” means you collect data; saying “we have evidence” means you can prove specific incident facts in a way regulators and courts will trust. For serious or regulator‑reportable incidents you are not just debugging a technical problem; you are assembling a case file that must support every material statement you make externally.

Under that lens, evidence needs qualities that everyday operational logging does not always guarantee: relevance to the facts in question, integrity (no unexplained modifications), clear provenance, completeness for the decisions you made and a documented trail of who handled it. A raw SIEM export with missing fields and no chain of custody may help engineers, but it will not satisfy a sceptical investigator.

A practical way to expose the gap is to take one real incident and ask, “If a regulator arrived tomorrow, could we show them, within a day, a consistent pack that explains what happened and backs every key statement we made?” If the honest answer is no, your risk is not hypothetical. That gap then becomes the narrative starting point for your evidence‑collection work.

How to baseline your current evidence posture

A quick evidence baseline compares a few real incidents against what you would need to convince a regulator that your version of events is accurate. By sampling different incident types and listing which artefacts you have and which are missing, you turn vague anxiety into a concrete, prioritised improvement list that both security specialists and non‑technical leaders can understand.

To baseline without huge effort, pick three to five incidents from the past year: one personal‑data breach or near miss, one major availability or integrity incident and one third‑party‑driven event. For each, list which artefacts you actually have today-logs, reports, emails, tickets, screenshots, meeting notes-and which you wish you had.

Summarise the findings in a short internal note; for example, In four of five cases, identity logs were incomplete; in three, we lacked a clear decision log; in two, we could not reconstruct the exact detection time. That lightweight analysis instantly turns vague discomfort into a concrete baseline. It also gives you a simple, non‑alarmist way to explain to leadership why ISO 27001s evidence‑collection control deserves attention now, rather than after the next breach.

If your organisation is still working towards its first ISO 27001 certification, this baseline can also feed directly into your risk assessment and treatment plan. Evidence gaps around regulator‑reportable incidents usually justify clear, actionable risk treatments rather than being parked for later.

Book a demo

What ISO 27001 A.8.28 (formerly A.5.28) really asks of you

ISO 27001 A.8.28 (which older materials may still label A.5.28) requires you to handle incident evidence through a defined, repeatable process rather than improvising during a crisis. ISO 27001:2022 expects you to establish and implement procedures for identifying, collecting, acquiring and preserving evidence related to information security events. In practice, that means deciding in advance what counts as evidence, where it lives and how it is handled, and being able to show auditors and regulators that these activities fit your risk profile and sector instead of relying on ad hoc “grab what you can” behaviour.

In simple terms, the control expects you to do four things:

Decide what counts as potential evidence and where it resides.:
Collect it in a controlled way that preserves its value.:
Store and protect it securely for as long as it is needed.:
Show that you do this systematically, not occasionally.:

If you use an integrated ISMS platform such as ISMS.online, you can turn these expectations into concrete workflows, responsibilities and artefact libraries, rather than relying on static documents and personal memory.

This information is general and does not constitute legal advice; you should always take jurisdiction‑specific guidance from qualified counsel or your data protection officer when interpreting regulatory duties.

The core requirement in plain language

In plain language, A.8.28 requires you to be able to tell a credible, verifiable storey about serious incidents, backed by evidence you can find and trust, in a way that stands up to challenge. The standard does not force you to treat every minor event like a criminal investigation or demand laboratory‑grade forensics, but it does expect you to define when a more disciplined approach applies and how you will execute it consistently across security, privacy and resilience needs, using procedures rather than improvisation. Those procedures should cover at least:

When an event becomes an incident that needs evidencing.:
Who is authorised to start collecting evidence and record that decision.:
Which sources they must use for different incident types.:
How they collect from those sources without corrupting data.:
How they label, store and secure the resulting artefacts.:

It also expects you to think about how this dovetails with other controls. Logging and monitoring generate much of the raw material. Incident‑management controls define how you plan for, detect, assess and respond to events. Legal and regulatory controls define external duties. Evidence collection sits between these, ensuring that what starts as technical telemetry ends life as a coherent record that underpins your response and your accountability.

Where A.8.28 fits alongside other ISO 27001 controls

A.8.28 fits between logging, incident‑management and legal controls as the bridge that turns technical signals and decisions into a defensible case file. Many teams initially misread the control as “more logging”, but logging is already addressed elsewhere. Evidence collection is that bridge: it takes relevant pieces from your logging, monitoring, incident response, legal, privacy and records‑management practices and turns them into something that can withstand scrutiny.

A useful way to think about it is to sketch a simple map: A.5.24–A.5.27 for incident planning, assessment, response and learning; logging controls for generating and protecting events; and A.8.28 in the middle, transforming those events and the associated decisions into a managed evidence trail. Once you see that picture, it becomes much easier for CISOs, privacy officers and practitioners to spot where responsibilities overlap, where gaps exist and how to tune the level of formality to the risk level of your organisation and sector.

For a first‑time ISO 27001 adopter, this often means starting with a light‑touch evidence procedure for high‑severity incidents and gradually extending it, rather than trying to retrofit full forensic discipline into every minor ticket on day one.

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

From security event to regulator‑reportable case

A simple, repeatable journey from initial detection to regulator‑reportable case makes it far easier to collect evidence at the right times and in the right form. Your goal is not to treat every event as a legal case, but to ensure the process naturally becomes more structured as impact and regulatory relevance increase, particularly for incidents that fall under data‑breach or cyber‑resilience laws.

Not every suspicious log entry becomes an incident, and not every incident becomes a regulator‑reportable case. Yet your evidence‑collection process needs to handle the entire journey smoothly, especially at the point where a routine event turns into a matter of legal and regulatory record with strict timelines and prescribed content for notifications.

In practice, the journey usually follows a familiar pattern. A monitoring system or user raises an event. SecOps triage the event and, if warranted, declare an incident. Further investigation reveals whether personal data, critical services or regulated systems are involved. Legal and privacy teams assess whether regulatory thresholds have been crossed. If they have, notification clocks start, and evidence must support every factual claim you make externally.

Understanding when an incident crosses the reporting threshold

You cannot collect evidence intelligently without a clear view of when an incident becomes regulator‑reportable. That tipping point is usually defined by law or sector rules, but in practice you need a simple, internal description of the scenarios that automatically trigger more formal evidence handling and privacy or legal review.

Each law and sector rule has its own language, but most ask similar questions: did the incident affect confidentiality, integrity or availability of particular data or services; how serious and how long‑lasting was the impact; and what is the likely risk to affected individuals, customers or society. Your procedures should therefore define, in your own words, what “regulator‑reportable” means for you, with concrete examples and clear links to your risk appetite.

For example, you might say that any incident involving confirmed exfiltration of unencrypted customer data in the European Economic Area automatically triggers a joint security–privacy assessment for regulatory notification. At that point, your evidence process should ensure you can quickly show which records were involved, how and when access occurred, what your detection and response timelines were and how you assessed risk. Because thresholds and deadlines differ across jurisdictions, your definitions should be reviewed with your data protection officer and external counsel.

Making evidence part of your escalation path

Once thresholds are clear, evidence must be built into each step of your escalation path rather than bolted on at the end. That means scripting when responders secure key artefacts, when legal and privacy expect a partial case file and how those activities are recorded so you can show they happened in time for tight notification windows.

Once you have defined thresholds, build evidence checkpoints into each stage of your escalation path. When the SOC moves an event into “major incident” status, responders should know which log sources and artefacts to secure immediately. When legal and privacy become involved, they should find a partially built file already waiting-key system logs, initial impact analysis, key communications-rather than starting from scratch under time pressure.

It also helps to use consistent templates for incident and breach assessments. These templates can ask, for each key statement (“we detected at time X”, “system Y was affected”, “we believe Z data was involved”), “What evidence supports this? Where is it stored? Who verified it?” Over time, this habit reduces the risk that your internal and external narratives drift apart or rely on untraceable recollections, and it gives privacy and legal officers more confidence when they sign off notifications in their own names.

For organisations that handle personal data or critical infrastructure, building these checkpoints into your ISMS-rather than treating them as optional good practice-can be the difference between a smooth regulatory interaction and a difficult one.

What good evidence looks like: integrity, chain of custody, admissibility

Good incident evidence is a set of artefacts that together tell a clear, believable storey and can withstand challenge from people outside your organisation. Regulators and courts will care at least as much about integrity, authenticity and chain of custody as they do about the raw technical detail, especially where people’s rights, safety or livelihoods are involved.

For evidence to be persuasive outside your own organisation, others must be able to trust that it is relevant, complete enough for its purpose and has not been altered without explanation. That is where ideas such as integrity and chain of custody come in. You do not need to become a criminal‑forensics laboratory, but you do need a level of discipline that would make sense to a regulator or court.

Good incident evidence is rarely a single file. More often, it is a collection of items-log exports, screenshots, disc images, chat transcripts, meeting notes, decisions and emails-that together tell the storey. The challenge is to ensure that as those items move between people and systems, they retain their value as proof rather than downgrading into “interesting but unverifiable” information.

Five qualities every incident evidence set must have

A simple checklist of five qualities-relevance, integrity, authenticity, completeness and chain of custody-gives you a clear standard for what “good enough” evidence looks like. If you regularly test real incidents against these qualities, weaknesses in your logging, storage or hand‑over practices quickly become visible and actionable for security, privacy and legal teams alike.

A practical test for your evidence is to look at those five qualities. Relevance: does each artefact clearly relate to a fact you might need to prove? Integrity: can you show that it has not been tampered with or accidentally modified, or if it has, that the changes were controlled and documented? Authenticity: can you demonstrate where it came from and that it is what it claims to be? Completeness: is there enough material to understand the key elements of the incident and your response without large unexplained gaps? Chain of custody: can you trace who created, accessed, transferred or analysed each piece, and when?

You can support these qualities with relatively straightforward measures: time‑synchronised systems so timestamps line up; standard export procedures that include hashes of key files; controlled folders or repositories with restricted write access; and a simple register that records when artefacts are created, moved or handed over to external parties. The goal is not perfection; it is to reduce the chance that a serious challenge to your evidence would reveal obvious weaknesses.

Balancing speed of response with evidential quality

In real incidents, responders are always balancing the need to act quickly with the need to preserve evidence. Your process should give them clear guidance on when to prioritise capture, when to prioritise containment and how to explain trade‑offs so regulators, customers and internal auditors can still trust the storey you tell afterwards.

Real incidents do not happen in slow motion. Teams under pressure may feel that stopping to image a system or script a clean export will delay containment. Your procedures therefore need to offer sensible guidance on trade‑offs: when must you secure evidence first, and when is it acceptable to fix immediately and rely on secondary sources later?

One helpful approach is to define a small set of “must‑capture quickly” artefacts for high‑risk scenarios, such as identity logs for administrator accounts, key firewall or proxy logs around the suspected window and a snapshot of relevant configuration settings. Responders can be trained to grab those as early as practical, even while containment is under way. When you do decide to take rapid action that might overwrite evidence, capture a short note in the incident record explaining why-that note often matters as much as the missing data when explaining yourself later.

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

Book your demo

Designing an A.8.28‑compliant evidence process

Designing an A.8.28‑compliant evidence process is about building a simple, end‑to‑end flow that people can actually follow under pressure. Instead of a long, static policy, you want a lifecycle that ties together roles, triggers, tools and metrics from preparation through to post‑incident learning, and that gives practitioners clear, achievable tasks rather than vague expectations.

Once you understand the control and what “good” looks like, the next challenge is design. An effective evidence‑collection process is not a single document; it is a set of connected practices spanning policy, roles, workflows, tools and metrics. It should be robust enough for stressful situations yet simple enough that people actually follow it, including busy engineers, service managers and privacy or legal advisers.

Most organisations find it useful to think in terms of a lifecycle: preparation, identification, collection and acquisition, preservation, analysis and closure. ISO 27001’s evidence‑collection requirement sits across that lifecycle and must also be aligned with your incident‑management plan, information security policy, data‑protection governance and records‑management rules.

A simple incident‑to‑evidence lifecycle

You can express your evidence lifecycle in a small number of phases:

Preparation: define procedures, catalogues, roles, tools and training.
Identification: decide which events or incidents require formal evidence.
Collection and acquisition: gather artefacts from agreed sources in a controlled way.
Preservation: store them securely with access controls and change tracking.
Analysis and closure: use them to understand the incident, report and learn.

Once this is sketched, you can align your existing policies and tools with each phase and identify where you need new playbooks, training or technology.

Build an end‑to‑end incident‑to‑evidence flow

A visual incident‑to‑evidence flow diagram makes the control far easier to implement and to explain to others. It shows how your existing incident processes, logging, legal reviews and communications join up, and where evidence steps need to be triggered so that nothing important is missed, particularly for regulator‑reportable scenarios.

Start by sketching a high‑level flow that links your existing processes. Show how an event enters the incident queue, how it is assessed, when an incident is declared, when evidence steps begin, who is notified and when regulatory notifications or customer communications are considered. For each major step, ask, “What evidence should exist at this point?” and “Where does it go?”

With that picture in place, you can design concrete procedures and playbooks. These might include a general evidence‑collection standard plus shorter, incident‑type‑specific checklists. They should also define the triggers that move you from light‑touch documentation to more formal evidence handling-for example, when an incident reaches a certain severity, affects certain systems, or is likely to be notifiable under relevant law.

Embed roles, trigger points and KPIs

Defining clear roles, trigger points and simple performance indicators turns your evidence process from a policy into a working capability. People know what to do when severity jumps, and you can see in management reviews whether the process is being used and where it is failing, which is particularly valuable for CISOs, DPOs and frontline practitioners.

A well‑designed process also makes clear who is responsible for what. Security operations teams are usually responsible for technical collection and initial preservation. Legal and privacy functions help interpret regulatory thresholds and oversee how potentially sensitive material is handled and shared. Risk and compliance teams coordinate audits, management reviews and interactions with regulators or certification bodies.

Documenting these responsibilities in a simple responsibility matrix removes guesswork in the middle of a crisis. To make the process measurable, define a small number of indicators; for example, the proportion of significant incidents with a complete evidence checklist; time from incident declaration to securing agreed “must‑capture” artefacts; and the number of post‑incident reviews that identify evidence gaps. Reviewing these periodically as part of your management review turns A.8.28 from a static control into a living capability and gives practitioners recognition for doing this work well.

An ISMS platform such as ISMS.online can help by providing a single place to link incidents, controls, evidence, actions and reviews, so that defined responsibilities and flows show up as day‑to‑day tasks rather than remaining on paper. For your implementation plan this quarter, that might mean piloting the full lifecycle on one high‑risk system or business unit and using the results to refine your organisation‑wide design.

Your incident evidence catalogue: logs and artefacts that matter

An incident evidence catalogue is a focused list of log sources and artefact types you rely on for serious incidents, mapped to owners and locations. It keeps your process practical by making it clear what to collect for different scenarios, without trying to track every possible data source in your environment, and it helps practitioners move quickly without constantly asking “where does this live?”.

Even a well‑designed process will fail if people do not know what to collect. That is where an evidence catalogue comes in. This is a structured list of the log sources and other artefacts you rely on for different incident types, along with key details such as owners, locations and any constraints on use.

A catalogue should also make clear who is accountable for each source and how often it is checked or refreshed. That way, responders are not trying to discover basic information during an incident, and IT and security teams can keep the catalogue manageable instead of trying to track every system in your environment.

Prioritise the log sources you actually need

Prioritising a small set of essential log sources for your top incident scenarios keeps the evidence catalogue usable. For each category-identity, network, application, host, cloud-you decide which systems really matter and what minimum fields you need to reconstruct events reliably, rather than trying to log everything at maximum detail.

For most organisations, a core set of logs covers a large share of serious incidents: identity and access logs; key network and perimeter logs (for example, firewalls, VPN and proxy); critical application and database logs; host‑level security telemetry; and relevant cloud or SaaS audit logs. For each, specify the basic fields you require-timestamps, user or service IDs, source and destination, action taken, result and perhaps contextual fields such as location or device type.

You can then map these sources against your top incident scenarios. For each scenario-say, compromised administrator account, data exfiltration from a cloud storage bucket, or unauthorised access to a payment system-list which log sources you expect to rely on. If you find that a scenario cannot be reconstructed with your current logging, that insight feeds back into both your logging strategy and your evidence‑readiness improvements, and it gives practitioners a clear justification for logging changes when they talk to budget holders.

Go beyond logs to a full case file

An effective evidence catalogue also lists the non‑log artefacts that complete the incident “case file”: screenshots, configurations, tickets, emails and notes. These items provide human context, document decisions and capture transient system states that might never appear fully in logs, which is particularly important for privacy officers and legal teams who must stand behind formal notifications.

Logs are vital, but they are not the whole storey. Non‑log artefacts such as screenshots, configuration exports, disc or memory images, email or chat transcripts and ticket histories also matter. They provide human context, capture transient states and document how decisions were made.

A simple table can help bring structure to this wider set:

Evidence type	Typical use in an investigation	Key cautions
Log exports	Timelines, sequence of technical events	Protect integrity, limit scope
Disc or memory images	Deep analysis of compromised systems	High sensitivity, large volume
Screenshots	Capturing transient screens or states	Avoid extraneous personal data
Email/chat extracts	Decisions, notifications, instructions	Respect privilege and privacy
Tickets and notes	Workflow, approvals, hand‑offs	Keep entries factual, time‑stamped
Configuration exports	Understanding security posture at time	Protect secrets, control access

For each artefact type in your catalogue, record who owns it, where it should be stored, how long it should be kept and any special handling rules (for example, only accessible to certain roles or subject to legal privilege). This makes it far easier to assemble a consistent case file when a real incident occurs, and to show auditors that you have thought about evidence beyond raw log lines.

If you use a platform like ISMS.online to host your ISMS, you can link catalogue entries directly to incident types and playbooks, making it easier for responders to see “what to collect” in context rather than searching separate documents.

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

Book your demo

Aligning ISO 27001 A.8.28 with GDPR, NIS 2 and sector rules

Aligning A.8.28 with GDPR, NIS 2 and sector rules is about designing one evidence trail that can answer many different regulatory questions. Instead of running separate, parallel processes, you build a single, coherent record that supports security, privacy and resilience expectations, giving CISOs, privacy officers and legal counsel a common view of what “defensible” looks like.

Evidence collection does not happen in a vacuum. The same events and artefacts that matter for ISO 27001 also underpin your obligations under privacy and cybersecurity laws such as GDPR and NIS 2, and any sector‑specific rules that apply to you. Instead of designing separate processes for each regime, you can usually design once and map many times, as long as you understand the different thresholds and timelines.

This is where a unified view of obligations becomes important. By listing your ISO 27001 controls alongside key regulatory duties-for example, security of processing, breach notification and incident reporting-you can see where a single incident evidence trail can support multiple expectations. That saves effort and reduces the risk of contradictory stories, which is a particular concern for DPOs and legal officers who may be personally named in enforcement actions.

Mapping one evidence trail to many regimes

A practical way to align ISO 27001 evidence requirements with laws and sector rules is to reverse‑engineer the questions those regimes ask after an incident. Once you know which answers you will be expected to provide, you can design your incident file so that each section is clearly tied to one or more recurring regulatory questions.

Start by identifying the main regulatory questions you must be able to answer after a serious incident. Typical themes include what happened; when you first knew; which systems and data were affected; how many users or customers were impacted; what the consequences were; what measures you had in place; what you did in response; and how you assessed the need to notify and to offer remedies.

Once you have these question sets, map them to elements of your incident evidence file. For example, log exports and alerts may support the “what and when” questions; asset and data‑flow registers support “which systems and data”; ticketing and change records support “what you did and when”; and risk assessments and legal notes support “how you judged the impact and notification need”. By designing your evidence process around these recurring questions, you make it much easier to complete regulatory templates accurately and consistently, even when different jurisdictions or sector regulators ask for slightly different formats.

Applying privacy by design to evidence collection

Applying privacy by design to evidence collection means treating incident artefacts as personal and sensitive data in their own right. You minimise what you collect, limit who can see it, control how long you keep it and document the legal and business reasons for each decision, in collaboration with your data‑protection and records‑management functions.

Logs and incident artefacts frequently contain personal data, commercially sensitive information and sometimes material that could be legally privileged. That means your evidence‑collection process must also reflect privacy‑by‑design principles such as minimising what you collect, limiting the purposes for which you use it and defining retention periods that make sense in light of legal and business needs.

In practical terms, this might mean scoping log and evidence collection to relevant time windows and systems, redacting or pseudonymising certain identifiers in derived copies used for training, and applying stricter access control to highly sensitive artefacts. It also means documenting your rationale: why you keep certain data for a given period; how you separate material needed for long‑term legal defence from data that can safely be aggregated or deleted sooner; and how individuals’ rights are respected even in the context of security investigations.

Coordinating these decisions between security, privacy, legal, records management and internal audit reduces friction later. It also gives you a stronger footing if a regulator ever asks, “Why did you collect and keep this, and for how long?”, and it reminds everyone that incident evidence itself is a record subject to your broader governance framework.

Book a Demo With ISMS.online Today

ISMS.online helps you turn ISO 27001 A.8.28 from a line in a standard into a working, cross‑functional evidence‑management capability that your teams can follow during real incidents. By centralising incidents, controls, evidence, tasks and approvals in one environment, the platform makes it much easier to embed evidence‑by‑design into your daily operations instead of relying on improvised workarounds or fragile spreadsheets.

See an A.8.28 evidence playbook in action

Seeing an end‑to‑end evidence playbook running in a live system is often the fastest way to decide whether your current approach is sustainable. A focused demonstration lets you test how incident records, evidence checklists and approval flows could look in practice for your own organisation and where they could reduce effort for CISOs, DPOs and practitioners.

In a typical deployment, you can model your incident‑to‑evidence flow directly in ISMS.online: incident records link to the relevant controls, pre‑built evidence checklists, assigned owners and due dates. As responders capture artefacts-log exports, screenshots, meeting notes-they attach them to the incident, building a structured file that supports internal reviews, ISO audits and external notifications.

Because everything sits inside one ISMS rather than across spreadsheets and shared drives, you can also reuse evidence where appropriate. A single incident file can help you demonstrate conformance with multiple controls and regulatory duties, rather than having to collate new packs each time.

A short, scenario‑based demonstration is often the fastest way to see whether this model fits your organisation. Walking through a realistic breach example in the platform lets you test how well it matches your existing tools and where it could remove friction and manual work.

Pilot structured evidence management before the next big incident

Piloting structured evidence management on a limited scope lets you prove value before you roll it out more widely. You pick one or two high‑risk incident types or business units, configure an A.8.28‑aligned playbook and run a real or simulated incident through it. The comparison with your current approach is usually revealing for technical and non‑technical stakeholders.

You do not have to redesign everything at once. Many organisations start by piloting structured evidence management for one or two high‑risk incident types or business units. They configure an A.8.28‑aligned playbook in ISMS.online, run a live incident or tabletop exercise through it and compare the outcome with their current approach: how long it took to assemble evidence, how complete the record feels and how easily they could answer typical regulator questions.

From there, you can decide whether to extend the approach, refine it or bring in additional teams such as privacy and legal more deeply. A time‑boxed pilot with clear evaluation criteria gives you real data on usability, effort and benefits, rather than leaving you to rely on assumptions.

If you want your next serious incident to feel more like the execution of a well‑rehearsed plan and less like a hunt through half‑remembered logs and inboxes, booking a demo with ISMS.online is a practical next step. It gives you and your colleagues a concrete view of how an integrated ISMS can support evidence‑by‑design, ISO 27001 conformance and regulator‑ready incident handling, all in one place, so you can face tough questions with confidence rather than hope.

Book a demo

Frequently Asked Questions

You don’t need more copy; you already have a strong, clear FAQ set.

The “critique” block is essentially just a lightly re‑phrased duplicate of your draught, which is why your scoring loop is stuck at 0: there’s no new signal, just repetition.

If your goal is to move this toward “final publish‑ready”, here’s what I’d do next rather than regenerate the whole thing:

Pick one version per question
For each FAQ, choose either the “FAQ Draught” or the “Critique” version. Differences are small (wording like “in practice” vs “in plain terms”), so just keep the one that feels more natural to your house style and delete the other to avoid duplication.
Tighten one notch for web skim‑readers
In each answer:

Keep the opening sentence as is (they’re already concise and snippet‑friendly).
Scan for any paragraph over ~120 words and split once at a natural pause.
Leave bullets exactly where they are; they’re doing good work.

Add one neutral external reference, once
To satisfy YMYL/credibility without clutter:

At the end of the “What does ISO 27001 A.8.28 really expect…” answer, add a short, neutral line such as:

 “You can cross‑check your interpretation against the latest ISO 27001:2022 text and any applicable regulator guidance, for example your national data protection authority’s breach‑notification FAQs.”

No URL needed if your style guide prefers to avoid linking to standards.

Make the ISMS.online benefit line slightly more identity‑anchored
Your existing brand mentions are solid but you can sharpen them just a little so they speak more directly to the reader’s role. For example, in the last FAQ:

Current:

If you want your next serious incident to feel less like a scramble…

Possible tweak:

If you want your next serious incident to feel less like a scramble and more like the measured response your board expects from you, it’s worth comparing your current approach with a unified, evidence‑by‑design ISMS such as ISMS.online.

Check clause language once
Your description of A.8.28 (evidence collection, preservation, admissibility) is aligned with common interpretations. Just do a quick internal cross‑check against your organisation’s preferred clause summary to ensure wording doesn’t conflict with existing guidance.

If you’d like, paste the single chosen version of each FAQ and I can:

Do a light pass to remove tiny redundancies.
Add that one external‑guidance reference.
Thread in a couple of identity‑anchored phrases for CISOs / Kickstarters without changing your structure or tone.

ISO 27001 A.8.28 – Evidence Collection for Regulator-Reportable Incidents