Cyber Incident Response for Regulated Records
A cyber incident in a regulated environment starts two responses at once. The security response asks whether the intrusion is contained, how it got in, and what has to be rebuilt. The quality response asks a question security teams are not trained to ask: which regulated records were touched, can they still be trusted, and what does that mean for product already made and about to be released. Organisations that rehearse only the first find the second in the middle of the incident, at the point where the answer is most expensive.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 24 LINKSFor a regulated organisation the incident question is not only whether attackers got in, but whether the records can still be trusted afterwards — and that is a data-integrity determination, not an IT one.
06 · QUALITY MATURITY — CYBER INCIDENT RESPONSE FOR REGULATED RECORDS, REACTIVE TO ADAPTIVE
An incident is an IT matter. Quality hears about it if service is disrupted, and the records question is never asked.
A response plan exists and IT would follow it, but it has no quality trigger and no step that assesses whether data was altered.
The plan has a defined point at which quality is engaged, records integrity is assessed explicitly, and the assessment can conclude that data cannot be relied on.
Response is exercised rather than written, forensic readiness is arranged in advance, and lessons reach the quality system as CAPA rather than as an IT action item.
Detection and containment are fast enough that the integrity question is narrow, and the organisation can state which records were affected rather than which systems.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 5 regulatory bodies: FDA, EMA, MHRA, ISO, IEC.
RECORDS & OBJECTIVE EVIDENCE
- The incident response plan, with its quality engagement trigger
- The data-integrity assessment step, and any completed assessments
- Exercise records, including what the exercise revealed
- Log retention arrangements sufficient to reconstruct what happened
- CAPA arising from incidents, with effectiveness verification
COMMON INSPECTION FINDINGS
- An incident closed on service restoration with no assessment of record integrity
- Quality unaware of an incident affecting a system holding GxP records
- Logs retained for too short a period to establish what was accessed or changed
- A plan that has never been exercised, so its first execution is a real event
- Incident lessons recorded as IT actions and never entering the quality system
Two clocks, and they run in parallel
The regulatory clocks start on awareness, not on resolution. Where personal data is involved, GDPR Article 33 requires notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach. The NIS2 Directive, (EU) 2022/2555, adds a staged sequence for significant incidents at entities in scope: an early warning within 24 hours, a full incident notification within 72 hours, and a final report within one month of that notification, with a progress report instead if the incident is still ongoing. Member States were required to transpose it by 17 October 2024, and the detail of who is in scope is set nationally.
NIS2 reaches much of this sector. Its health sector covers entities holding a manufacturing authorisation for medicinal products, manufacturers of basic pharmaceutical products and preparations, and manufacturers of devices considered critical during a public health emergency, with size thresholds determining whether an entity is essential or important. For most life-sciences organisations the practical consequence is that a manufacturing outage caused by an intrusion is now a reportable event on a fixed clock, in addition to whatever the quality system requires.
Alongside these sit the obligations the organisation already had. EU GMP Annex 11 requires that all incidents — not only system failures and data errors — are reported and assessed, with the root cause of a critical incident forming the basis of corrective and preventive action. For a marketed device, a security incident with safety or effectiveness implications can trigger complaint handling and vigilance reporting on their own timelines.
The question a security team does not ask
Incident response frameworks are built around confidentiality, integrity and availability of systems. GxP response is built around the trustworthiness of records. These overlap but they are not the same, and the difference shows up in scoping: a security team declares an incident closed when the attacker is evicted and systems are restored, while the quality question — whether records created, modified or restored during the incident window can be relied on — is still entirely open.
The assessment that has to be performed is specific. Establish the incident window from first compromise to full recovery, not from detection. Enumerate the GxP systems reachable from the compromised assets. For each, determine whether records were created or modified in that window, whether the audit trail covering it survived intact, and whether it is independently corroborated — by a second system, an instrument’s own log, or a paper record. Where corroboration is absent and integrity cannot be established, the affected records are not usable as evidence of quality, and that conclusion has to be reached deliberately rather than assumed away because the systems came back up.
Continuity, backups, and restoring into a validated state
Annex 11 requires that systems supporting critical processes have documented, tested continuity provisions — a manual or alternative arrangement — with the time to bring them into use based on risk. It also requires regular backups whose integrity, accuracy and restorability are checked during validation and monitored periodically. Both requirements are routinely satisfied on paper and rarely exercised at the scale an incident demands: a restore test of one system on a quiet afternoon proves very little about restoring forty systems in a defined order with the network segmented.
A restore is itself a data-integrity event. The restored system must be verified back into a validated state, and the gap between the last known-good backup and the incident has to be reconstructed and reconciled — from paper, from upstream systems, or acknowledged as lost. This is also why recovery objectives expressed only in hours mislead in a manufacturing context. The operationally meaningful statements are how many batches are in flight, what happens to the ones mid-process, and how long the manual fallback can carry production before the record backlog becomes the constraint.
Ransomware sharpens the record question
Ransomware makes the integrity problem acute because the same event both denies availability and casts doubt on everything the attacker could reach. The decision that dominates public discussion — whether to pay — is not the GxP decision. The GxP decisions are the provenance of the restored data, the trustworthiness of records in the gap, and the disposition of product manufactured or tested while the systems were unavailable.
Batch disposition during an outage is where this becomes concrete. Manufacturing on documented paper fallback is legitimate where the fallback is a defined, trained, previously tested part of the continuity arrangement; it is not legitimate when it is improvised during the incident, because the resulting records were produced under an unqualified process. The authorised person or quality unit making the release decision needs the integrity assessment, not just confirmation that the systems are back.
SPEQ interpretation — rehearse the integrity assessment, not only the restore
Most regulated organisations test disaster recovery, and the test measures how long a restore takes. Almost none rehearse the record-integrity assessment, and that is the step that determines whether product can be released. The result is predictable: recovery goes roughly to plan, and then several days are lost working out what the records mean, with the quality unit assembling an assessment method while under pressure to release.
The cheap fix is to make the assessment method an artefact rather than an improvisation — a documented procedure that names the GxP systems in scope, states how the incident window is established, defines what corroboration is acceptable for each system, and pre-agrees who signs the conclusion. Written in advance it takes a day. Written during an incident it takes a week, and it is written by people who have not slept.
FREQUENTLY ASKED
Does a cyber incident have to be raised as a GMP deviation?
If it affected a GxP system, a GxP record, or the ability to manufacture or test to the approved process, yes. EU GMP Annex 11 requires that all incidents are reported and assessed, and that the root cause of a critical incident forms the basis of corrective and preventive action. The security ticket and the deviation record serve different purposes and both are needed; tracking the incident only in security tooling leaves the quality system with no record of an event that affected product.
What are the NIS2 reporting deadlines, and do they apply to pharmaceutical manufacturers?
For a significant incident, NIS2 requires an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report within one month of that notification, with a progress report if the incident is still ongoing. The health sector in scope includes holders of a medicinal-product manufacturing authorisation and manufacturers of devices considered critical during a public health emergency, subject to size thresholds — but the Directive is implemented through national law, so the precise scope and reporting route are set by each Member State.
Can product manufactured on paper during an outage be released?
It depends on whether the paper process was a defined, trained and previously tested part of the continuity arrangement, or improvised during the incident. Annex 11 expects continuity arrangements for systems supporting critical processes to be documented and tested. Where the fallback was qualified in advance, records produced under it are usable; where it was invented under pressure, the release decision has to address the fact that the process itself was not approved.
Is restoring from backup a validated activity?
The ability to restore is a validation deliverable — Annex 11 requires backup integrity, accuracy and restorability to be checked during validation and monitored periodically. A production restore following an incident is a change to a validated system: it needs verification that the system returned to its validated state and reconciliation of the gap between the last good backup and the incident.
How is the incident window established for a record-integrity assessment?
From first compromise to full recovery, not from detection to containment. The interval between initial access and discovery is frequently the longest part of an incident and is exactly the period in which records were created while an unauthorised party had access. Establishing it depends on forensic evidence and log retention, which is one practical reason to retain GxP system logs long enough to answer the question.