[ ENTERPRISE PILLAR 11 ]
Protect people, products, operations, evidence, and continuity by governing cyber and privacy risk across enterprise IT, OT, products, suppliers, and AI.
Cybersecurity is not a synonym for data integrity or IT. It spans enterprise IT, OT, products, laboratories, cloud, suppliers, privacy, incident response, and continuity.
The capability framing below, its failure modes and the boundary with neighbouring pillars are SPEQ’s practitioner reading — not a regulatory requirement, and not an assessment of any organization.
THE CAPABILITY
This capability is what an organization does once it accepts that some part of its environment is hostile and it still has to operate. That single assumption is what binds together things that otherwise share nothing: an office network, a controller on a filling line, a marketed device in somebody's chest, a supplier with a standing remote session, and a dataset about identifiable people. None of them is grouped here because of the technology involved. They are grouped because each is somewhere an adversary can act, and because the consequences of that action land on patients, on supply, and on the records the organization relies on to say what it did. Resilience is not a second subject bolted on at the end. It is what the capability is for after prevention has already failed, which it periodically will.
This is the only capability in the enterprise whose opposition is intelligent. Wear, variability, drift and ordinary human error are all indifferent to the measures placed against them; an adversary studies those measures, and a control that works is a control that has taught someone what not to try next. That one fact breaks the feedback loop everything else depends on. A quiet year in maintenance means the equipment is healthy. A quiet year here means either that nothing happened or that something did and nobody saw it, and from the inside those are indistinguishable — so the capability cannot read its own performance off its own outcomes. Scope is set from the outside too. The inventory that matters is whatever an attacker can reach, which routinely includes an analyser nobody ever listed as a computer, a vendor session opened for a two-week commissioning in 2019, and a product already sold and in use. Coverage can be complete against the list and still be wrong, because the defender wrote the list. Add that the strongest available controls make ordinary work slower and more irritating, and the capability spends credibility every time it quietly succeeds, in a currency it can only earn back by having failed.
Each of these happens with the individual branches below being run competently. That is what makes them capability failures rather than performance problems.
The servers, laptops and applications are inventoried and patched. The embedded controller inside a laboratory analyser, the environmental monitoring unit with a web interface, the building management panel and the instrument running an operating system that went out of support a decade ago are none of them on the asset register, because the people who bought them bought equipment. They are on the network all the same.
A legacy system cannot take the patch, so a compensating control and a documented acceptance are put in place, correctly, for a year. It is renewed, correctly, the next year and the next. Nothing is hidden and every renewal is signed. A decade later the organization is operating on a set of accepted exceptions large enough to constitute its actual security posture, and no single renewal was the point at which anyone should have said no.
The exercise restores servers in dependency order, hits its target, and is reported as a success. What it did not rehearse is the shift that has to keep running for the eleven hours while that happens: which activities stop, what the paper fallback actually is, who is authorised to use it, and how work performed during the outage rejoins the record afterwards. The technical plan is tested annually and the operating plan has never been read.
Questionnaires come back, certificates go on file, and the folder grows. What is rarely done is the comparison between what the supplier attested and what the supplier can actually reach — the standing account, the network route, the data it holds. Assurance accumulates at the entity level while risk sits at the connection level, and the two are never put side by side.
WHERE THIS STOPS
Security protects records; it does not decide what they mean or whether they can be relied on, and the reconciliation of a validated state after an incident is its own seam with its own owners rather than something this pillar concludes alone. It sets the architecture and the access model for industrial systems while automation keeps the control function and its availability, which is why the patch window is negotiated rather than instructed. It secures buildings only in the digital sense — badge readers and cameras are its systems, but who may be where is a physical-security and site matter. Privacy shares the pillar because protection and lawful handling use the same controls, though whether a use of personal data is permitted at all is a legal determination, not a security one. The seam that generates the most argument is a vulnerability in a product already on the market: the same finding is a defect to be patched on an engineering clock and a potential harm to be evaluated on a vigilance clock, and organizations that have not agreed in advance who makes that call end up making it twice, in two forums, at different speeds.
No, and treating it that way is what leaves the gaps. Enterprise security optimises for confidentiality first and can usually take a system offline to be safe. In a regulated operation, taking the wrong system offline stops production or blinds a monitoring function, integrity of a record can matter more than its secrecy, and some of the assets are inside patients. The discipline transfers; the ordering of priorities and the available responses do not.
Because they fail into each other. A ransomware event is simultaneously a security incident and a continuity event, and an organization that has separated the two ends up running two incident commands with one set of people. Keeping them together also forces an honest question that a purely preventive framing avoids: assuming a control has already failed, what does the operation do for the next three days.
By treating the exception as having an expiry and an owner rather than a renewal. A compensating control is a legitimate answer to a system that cannot be updated; what turns it into a problem is that its review asks whether the control is still in place instead of whether the underlying system is still tolerable. The useful discipline is to keep the accepted exceptions visible as one portfolio, so their aggregate is something a person has to look at.
A vulnerability is a weakness that could be exploited; an incident is something that happened. The distinction matters because they trigger different work: a vulnerability is triaged, risk-assessed and remediated on a planned clock, while an incident starts a response, an impact assessment and, potentially, notifications. Where organizations get into difficulty is the middle case — evidence of attempted exploitation — which is handled as a vulnerability by teams measured on patching and as an incident by teams measured on detection.
CAPABILITY BRANCH MAP
How cyber risk is owned: strategy, accountability, stated risk appetite, policy, the regulatory obligations that apply, the metrics leadership sees, and the forum where decisions are actually taken.
Cybersecurity competes for the same resources as everything else, and it loses whenever it is framed as a technical matter. Governance is where the organisation decides how much residual risk it is accepting, which is a business decision that is frequently never explicitly made.
Knowing what exists and how exposed it is: IT, OT, IoT, cloud, software, data and identities, with dependencies, criticality and the resulting attack surface.
Every other control depends on the inventory. An asset nobody knows about is unpatched, unmonitored and unrecovered by definition — and in regulated manufacturing the forgotten assets are usually the ones connected to production.
Who can do what: identity lifecycle, authentication, authorisation, segregation of duties, service accounts, privileged access and the reviews that confirm access still matches the role.
Access is the control that most directly protects regulated records, and it is the one that decays fastest. People change role and keep their old rights, so entitlement accumulates until a long-tenured employee can do almost anything.
Protecting the data itself: classification, minimisation, lawful basis for use, encryption and key management, transfer, retention and defensible disposal.
Regulated organisations hold clinical, patient-safety and employee data under privacy law as well as GxP obligations, and the two regimes pull in different directions — one demands retention, the other erasure. That tension has to be resolved deliberately rather than per request.
The technical estate: network architecture and segmentation, secure configuration, cloud workload protection, endpoints, email, remote access and the monitoring across all of it.
Segmentation is what stops an ordinary compromise becoming a production outage. In a plant where the office network and the control network are reachable from one another, a phishing email is a manufacturing risk.
Securing the systems that run production: zones and conduits, secure remote access, industrial asset management, availability and safety constraints, change, recovery and the IT/OT coordination all of it needs.
Operational technology cannot be secured on IT terms — it cannot be rebooted on a schedule, patched promptly, or taken offline for scanning. The consequence of compromise is also different: not data loss but a process running outside its validated state, or not running at all.
Security of the product itself where it contains software: secure design, threat modelling, risk assessment, software bill of materials, testing, labelling, vulnerability handling, updates and postmarket surveillance.
For connected devices, cybersecurity is a safety characteristic and a premarket submission requirement. A vulnerability in a marketed device is a patient-safety issue handled under vigilance, not an IT ticket.
Security of how software is built and obtained: secure development lifecycle, code, dependencies, provenance, build and deployment pipelines, signing, bills of materials, release and vulnerability response.
Most software an organisation runs is code it did not write, arriving through dependencies and build pipelines. Provenance is what distinguishes a component that is what it claims to be from one that is not, and the pipeline itself is a high-value target precisely because it is trusted.
Cyber risk carried by other organisations: due diligence, contract terms, the access they hold, ongoing assurance, concentration risk, incident obligations and what happens at exit.
Suppliers hold credentials into the estate and copies of regulated data, so their weaknesses become the organisation’s exposure without appearing on its own inventory. Concentration is the quieter risk — many suppliers depending on one platform means one outage reaches everywhere at once.
Finding weaknesses and closing them: discovery, risk triage, compensating controls where remediation is not possible, tested remediation, configuration baselines, exceptions and the evidence of all of it.
Most compromises exploit something known and unpatched. In regulated environments the difficulty is not detection but change — patching a validated system requires assessment and testing, so the window between disclosure and remediation is structurally wider.
Noticing and handling an incident: log collection, detection, triage, containment, evidence preservation, notification obligations, eradication and what is learned afterwards.
Response quality is set before the incident, by decisions about logging, authority and rehearsal. During an incident there is no time to discover that the logs needed were never collected or that nobody is empowered to disconnect production.
Getting back to operating: recovery objectives, backups protected from the incident itself, tested restoration, alternate ways of working, crisis coordination, exercises and improvement afterwards.
Ransomware made recovery the primary control rather than a contingency. In regulated manufacturing, restoration is also a quality question — a recovered system must be demonstrably back in a validated state, not merely running again.
Threats specific to models and agents: attacks on training data and models, prompt and tool abuse, access to model capability, evaluation, monitoring, model supply chain, fallback and incident handling.
An AI system fails differently from other software: it can be manipulated through its ordinary input, and an agentic one can be induced to take actions with real consequence. The security boundary is the tools it can invoke, not the model itself.
The human layer: role-based expectations, resistance to social engineering, reporting culture, insider risk, exercises, and designing secure processes people can actually follow.
People are the most-attacked control and the fastest detector. Which of those dominates depends on whether reporting a mistake is safe — an organisation that disciplines the person who clicked will find out about the next incident considerably later.
CONNECTED OPERATING MODEL
MATURITY ORIENTATION · SPEQ SYNTHESIS
HIGH-VALUE INTERSECTIONS
SOURCE BASIS
REGULATORY BASIS
The 12 standards SPEQ maps to this pillar, and the 7 regulatory bodies behind them. Which standards belong to a pillar is a SPEQ judgement; the bodies, disciplines and industries below are read from the standards themselves.
EMA · FDA · IEC · IMDRF · ISO · ISPE · MHRA
Ranked by how many of this pillar’s standards each one cites — showing 10 of 47.
These 14 standards govern the system classes this pillar depends on rather than the pillar itself. The distinction matters: a standard that governs a system is not thereby a standard of every capability that uses it.
21 CFR Part 211ASTM E2500ISPE Baseline Guide Vol. 5 (2019)EU GMP Annex 15PIC/S PI 041-1FDA CSA Guidance (2026)ICH Q9(R1)ICH Q1021 CFR Part 820ISO 13485:2016ISO 9001:2015PIC/S PE 009-16ICH Q12EU GMP Annex 16
PROFESSIONAL · READINESS ORIENTATION
Rate observable operation from 0 (not established) to 4 (adaptive). The protected output prioritizes operating dimensions and evidence—not a compliance score.