Cybersecurity Governance in Regulated Organisations
Cybersecurity competes for the same resources as everything else, and it loses whenever it is framed as a technical matter. Governance is where an organisation decides how much residual cyber risk it is accepting — a business decision that in most organisations is never explicitly made, so it is made by default through the projects that did not get funded.
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 · 23 LINKSSecurity governance in a regulated organisation either connects to the quality system or duplicates it: risk, change, training, audit and supplier control exist in both, and running two of each is how the gap between them opens.
06 · QUALITY MATURITY — CYBERSECURITY GOVERNANCE IN REGULATED ORGANISATIONS, REACTIVE TO ADAPTIVE
Security is a function with a budget. Its relationship to GxP obligations has never been written down.
Policies exist on both sides and cross-reference each other, but risk registers, audits and training run in parallel with no shared view.
Security risks that affect regulated records or processes enter the quality risk process, and accountability for them is named in the same place as other quality accountability.
The two systems share their machinery — one change process, one CAPA, one supplier programme — so a security finding is handled by the system that already knows how to close findings.
Security posture is a standing input to quality governance, and a decision to accept security risk is made where product and patient impact is understood.
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, ICH, ISO, EC.
RECORDS & OBJECTIVE EVIDENCE
- The stated relationship between the security management system and the pharmaceutical quality system
- Security risks recorded in the quality risk process where they affect regulated outcomes
- Named accountability for security of GxP systems
- Management review inputs covering security posture
- Evidence that security findings use the same CAPA machinery as other findings
COMMON INSPECTION FINDINGS
- Two risk registers with no reconciliation, so a risk accepted in one is unknown in the other
- Security incidents and findings closed outside CAPA
- No named owner for the security of systems holding regulated records
- Security absent from management review inputs
- Policies that reference each other while the underlying processes never meet
An ISMS is a management system, and that is the point
ISO/IEC 27001 does not tell an organisation which controls to deploy. It requires a defined scope, a risk assessment, and a risk treatment process from which the Annex A controls are selected and justified — recorded in a Statement of Applicability that says which controls apply and why the excluded ones do not. That structure will be familiar to anyone who has built a pharmaceutical quality system, because it is the same shape: context, risk, documented decisions, internal audit, management review, continual improvement.
The scope statement is where certification claims quietly go wrong. A certificate covering a corporate head office says nothing about the site processing regulated data, and reading the Statement of Applicability is the only way to find out which. This matters most when assessing a supplier, where a certificate is often accepted as an answer rather than read as a document with a boundary.
Risk appetite is a decision, not a document
Most cyber programmes can articulate their risks and very few can state what level of residual risk leadership has agreed to carry. The consequence is that prioritisation happens implicitly: the vulnerability that stays open for eighteen months, the segmentation project deferred for three budget cycles, the legacy system nobody will fund replacing. Each of those is an acceptance of risk, taken without anyone framing it as one.
Making it explicit costs a forum and a record. A named body that reviews the significant residual risks, agrees which are accepted and for how long, and re-reads that list on a schedule. The value is not the document; it is that the acceptance becomes visible to the person who owns the consequence, which is usually not the person who deferred the work.
Where the ISMS meets the quality system
ISO/IEC 27001 governs the confidentiality, integrity and availability of information generally. EU GMP Annex 11, 21 CFR Part 11 and the data-integrity guidance govern the trustworthiness of the regulated record specifically. These overlap heavily and are not substitutes: an organisation can be certified and still have a data-integrity finding, because ALCOA+ attributes are not what the ISMS was assessed against.
The productive arrangement is to map rather than merge. Where a control satisfies both — access management, audit logging, backup and restore, change control — record it once and cite it to both regimes, so that evidence produced for one is usable in the other. Where they diverge, keep them separate. Merging the two into a single control set generally means the weaker requirement wins on both.
The regulatory obligations that now attach
Cyber governance in this sector no longer answers only to internal risk appetite. NIS2 brings much of the health sector into a regime with reporting duties on a fixed clock; GDPR imposes security-of-processing obligations under Article 32 and a 72-hour breach notification under Article 33; for connected devices, FD&C Act §524B makes cybersecurity a premarket condition. Each has its own trigger and its own owner, and an organisation that discovers the mapping during an incident discovers it too late.
The governance deliverable is unglamorous: a register of which cyber-relevant obligations apply to which entity and which product, with the reporting trigger and the accountable owner named for each. It is the same artefact regulatory affairs maintains for product obligations, and it is usually absent on the cyber side.
SPEQ interpretation — metrics that describe activity, not exposure
Cyber reporting to leadership is dominated by activity counts: phishing simulation click rates, tickets closed, training completion, patches applied. These are easy to produce and describe the programme rather than the exposure. Leadership reading them cannot tell whether the organisation is more or less likely to lose a manufacturing site this quarter than last.
The measures worth reporting are the ones that describe residual exposure and would change a decision: how many GxP-critical systems are running unsupported software and for how long, how many standing privileged accounts exist, the age distribution of unremediated critical vulnerabilities on production-reachable assets, and when the recovery of a critical system was last actually tested rather than planned. Those numbers are harder to produce, which is exactly why they are informative.
FREQUENTLY ASKED
Does ISO/IEC 27001 certification satisfy GxP data-integrity requirements?
No. ISO/IEC 27001 governs the confidentiality, integrity and availability of information generally; Annex 11, Part 11 and the data-integrity guidance govern the trustworthiness of the regulated record specifically, including the ALCOA+ attributes. Map the two so shared controls produce evidence usable in both regimes, but do not substitute one for the other.
What should a supplier’s ISO 27001 certificate be read for?
Its scope. A certificate covering a head office says nothing about the site that processes your data. Ask for the Statement of Applicability, read which Annex A controls were excluded and the justification given, and confirm the certified scope actually covers the service you are buying.
Who should own cyber risk in a regulated organisation?
Accountability sits with the business owner of the process the risk threatens, not with the security function, which owns the assessment and the controls rather than the acceptance. The practical test is whether the person accepting a deferred remediation is the person who would answer for the outage — if not, the acceptance is happening at the wrong level.
What cyber metrics are worth putting in front of leadership?
Ones that describe residual exposure rather than activity: GxP-critical systems on unsupported software and for how long, standing privileged accounts, the age of unremediated critical vulnerabilities on production-reachable assets, and when critical-system recovery was last actually tested. Click rates and tickets closed describe the programme, not the risk.