Annex 11 Section 5.1 “Cooperation”—The Real Test of Governance and Project Team Maturity

The draft Annex 11 is a cultural shift, a new way of working that reaches beyond pure compliance to emphasize accountability, transparency, and full-system oversight. Section 5.1, simply titled: “Cooperation” is a small but might part of this transformation

On its face, Section 5.1 may sound like a pleasantry: the regulation states that “there should be close cooperation between all relevant personnel such as process owner, system owner, qualified persons and IT.” In reality, this is a direct call to action for the formation of empowered, cross-functional, and highly integrated governance structures. It’s a recognition that, in an era when computerized systems underpin everything from batch release to deviation investigation, a siloed or transactional approach to system ownership is organizational malpractice.

Governance: From Siloed Ownership to Shared Accountability

Let’s breakdown what “cooperation” truly means in the current pharmaceutical digital landscape. Governance in the Annex 11 context is no longer a paperwork obligation but the backbone for digital trust. The roles of Process Owner (who understands the GMP-critical process), System Owner (managing the integrity and availability of the system), Quality (bearing regulatory release or oversight risk), and the IT function (delivering the technical and cybersecurity expertise) all must be clearly defined, actively engaged, and jointly responsible for compliance outcomes.

This shared ownership translates directly into how organizations structure project teams. Legacy models—where IT “owns the system,” Quality “owns compliance,” and business users “just use the tool”—are explicitly outdated. Section 5.1 obligates that these domains work in seamless partnership, not simply at “handover” moments but throughout every lifecycle phase from selection and implementation to maintenance and retirement. Each group brings indispensable knowledge: the process owner knows process risks and requirements; the system owner manages configuration and operational sustainability; Quality interprets regulatory standards and ensure release integrity; IT enables security, continuity, and technical change.

Practical Project Realities: Embedding Cooperation in Every Phase

In my experience, the biggest compliance failures often do not hinge on technical platform choices, but on fractured or missing cross-functional cooperation. Robust governance, under Section 5.1, doesn’t just mean having an org chart—it means everyone understands and fulfills their operational and compliance obligations every day. In practice, this requires formal documents (RACI matrices, governance charters), clear escalation routes, and regular—preferably, structured—forums for project and system performance review.

During system implementation, deep cooperation means all stakeholders are involved in requirements gathering and risk assessment, not just as “signatories” but as active contributors. It is not enough for the business to hand off requirements to IT with minimal dialogue, nor for IT to configure a system and expect the Qulity sign-off at the end. Instead, expect joint workshops, shared risk assessments (tying from process hazard analysis to technical configuration), and iterative reviews where each stakeholder is empowered to raise objections or demand proof of controls.

At all times, communication must be systematic, not ad hoc: regular governance meetings, with pre-published minutes and action tracking; dashboards or portals where issues, risks, and enhancement requests can be logged, tracked, and addressed; and shared access to documentation, validation reports, CAPA records, and system audit trails. This is particularly crucial as digital systems (cloud-based, SaaS, hybrid) increasingly blur the lines between “IT” and “business” roles.

Training, Qualifications, and Role Clarity: Everyone Is Accountable

Section 5.1 further clarifies that relevant personnel—regardless of functional home—must possess the appropriate qualifications, documented access rights, and clearly defined responsibilities. This raises the bar on both onboarding and continuing education. “Cooperation” thus demands rotational training and knowledge-sharing among core team members. Process owners must understand enough of IT and validation to foresee configuration-related compliance risks. IT staff must be fluent in GMP requirements and data integrity. Quality must move beyond audit response and actively participate in system configuration choices, validation planning, and periodic review.

In my own project experience, the difference between a successful, inspection-ready implementation and a troubled, remediation-prone rollout is almost always the presence, or absence, of this cross-trained, truly cooperative project team.

Supplier and Service Provider Partnerships: Extending Governance Beyond the Walls

The rise of cloud, SaaS, and outsourced system management means that “cooperation” extends outside traditional organizational boundaries. Section 5.1 works in concert with supplier sections of Annex 11—everyone from IT support to critical SaaS vendors must be engaged as partners within the governance framework. This requires clear, enforceable contracts outlining roles and responsibilities for security, data integrity, backup, and business continuity. It also means periodic supplier reviews, joint planning sessions, and supplier participation in incidents and change management when systems span organizations.

Internal IT must also be treated with the same rigor—a department supporting a GMP system is, under regulation, no different than a third-party vendor; it must be a named party in the cooperation and governance ecosystem.

Oversight and Monitoring: Governance as a Living Process

Effective cooperation isn’t a “set and forget”—it requires active, joint oversight. That means frequent management reviews (not just at system launch but periodically throughout the lifecycle), candid CAPA root cause debriefs across teams, and ongoing risk and performance evaluations done collectively. Each member of the governance body—be they system owner, process owner, or Quality—should have the right to escalate issues and trigger review of system configuration, validation status, or supplier contracts.

Structured communication frameworks—regularly scheduled project or operations reviews, joint documentation updates, and cross-functional risk and performance dashboards—turn this principle into practice. This is how validation, data integrity, and operational performance are confidently sustained (not just checked once) in a rigorous, documented, and inspection-ready fashion.

The “Cooperation” Imperative and the Digital GMP Transformation

With the explosion of digital complexity—artificial intelligence, platform integrations, distributed teams—the management of computerized systems has evolved well beyond technical mastery or GMP box-ticking. True compliance, under the new Annex 11, hangs on the ability of organizations to operationalize interdisciplinary governance. Section 5.1 thus becomes a proxy for digital maturity: teams that still operate in silos or treat “cooperation” as a formality will be missed by the first regulatory deep dive or major incident.

Meanwhile, sites that embed clear role assignment, foster cross-disciplinary partnership, and create active, transparent governance processes (documented and tracked) will find not only that inspections run smoothly—they’ll spend less time in audit firefighting, make faster decisions during technology rollouts, and spot improvement opportunities early.

Teams that embrace the cooperation mandate see risk mitigation, continuous improvement, and regulatory trust as the natural byproducts of shared accountability. Those that don’t will find themselves either in chronic remediation or watching more agile, digitally mature competitors pull ahead.

Key Governance and Project Team Implications

To provide a summary for project, governance, and operational leaders, here is a table distilling the new paradigm:

Governance Aspect	Implications for Project & Governance Teams
Clear Role Assignment	Define and document responsibilities for process owners, system owners, and IT.
Cross-Functional Partnership	Ensure collaboration among quality, IT, validation, and operational teams.
Training & Qualification	Clarify required qualifications, access levels, and competencies for personnel.
Supplier Oversight	Establish contracts with roles, responsibilities, and audit access rights.
Proactive Monitoring	Maintain joint oversight mechanisms to promptly address issues and changes.
Communication Framework	Set up regular, documented interaction channels among involved stakeholders.

In this new landscape, “cooperation” is not a regulatory afterthought. It is the hinge on which the entire digital validation and integrity culture swings. How and how well your teams work together is now as much a matter of inspection and business success as any technical control, risk assessment, or test script.

The Minimal Viable Risk Assessment Team

Ineffective risk management and quality systems revolve around superficial risk management. The core issue? Teams designed for compliance as a check-the-box activity rather than cognitive rigor. These gaps create systematic blind spots that no checklist can fix. The solution isn’t more assessors—it’s fewer, more competent ones anchored in science, patient impact, and lived process reality.

Cognitive Foundations of Risk Management Excellence

Core Roles: The Non-Negotiables

1. Process Owner: The Reality Anchor

Not a title. A lived experience. Superficial ownership creates the “unjustified assumptions.” This role requires daily engagement with the process—not just signature authority. Without it, assumptions go unchallenged.

2. ASTM E2500 Molecule Steward: The Patient’s Advocate

Beyond “SME”—the protein whisperer. This role demands provable knowledge of degradation pathways, critical quality attributes (CQAs), and patient impact. Contrast this with generic “subject matter experts” who lack molecule-specific insights. Without this anchor, assessments overlook patient-centric failure modes.

3. Technical System Owner: The Engineer

The value of the Technical System Owner—often the engineer—lies in their unique ability to bridge the worlds of design, operations, and risk control throughout the pharmaceutical lifecycle. Far from being a mere custodian of equipment, the system owner is the architect who understands not just how a system is built, but how it behaves under real-world conditions and how it integrates with the broader manufacturing program

4. Quality: The Cognitive Warper

Forget the auditor—this is your bias disruptor. Quality’s value lies in forcing cross-functional dialogue, challenging tacit assumptions, and documenting debates. When Quality fails to interrogate assumptions, hazards go unidentified. Their real role: Mandate “assumption logs” where every “We’ve always done it this way” must produce data or die.

A Venn diagram with three overlapping blue circles, each representing a different role: "Process Owner: The Reality Anchor," "Molecule Steward: The Patient’s Advocate," and "Technical System Owner: The Engineer." In the center, where all three circles overlap, is a green dashed circle labeled "Quality: Cognitive Warper." Each role has associated bullet points in colored dots:

Process Owner (top left): "Daily Engagement" and "Lived Experience" (blue dots).

Molecule Steward (top right): "Molecular specific insights" and "Patient-centric" (blue dots).

Technical System Owner (bottom): "The How’s" and "Technical understanding" (blue dots).

Additional points for Technical System Owner (bottom right): "Bias disruptor" and "Interrogate assumptions" (green dots).

The diagram visually emphasizes the intersection of these roles in achieving quality through cognitive diversity.

Team Design as Knowledge Preservation

Team design in the context of risk management is fundamentally an act of knowledge preservation, not just an exercise in filling seats or meeting compliance checklists. Every effective risk team is a living repository of the organization’s critical process insights, technical know-how, and nuanced operational experience. When teams are thoughtfully constructed to include individuals with deep, hands-on familiarity—process owners, technical system engineers, molecule stewards, and quality integrators—they collectively safeguard the hard-won lessons and tacit knowledge that are so often lost when people move on or retire. This approach ensures that risk assessments are not just theoretical exercises but are grounded in the practical realities that only those with lived experience can provide.

Combating organizational forgetting requires more than documentation or digital knowledge bases; it demands intentional, cross-functional team design that fosters active knowledge transfer. When a risk team brings together diverse experts who routinely interact, challenge each other’s assumptions, and share context from their respective domains, they create a dynamic environment where critical information is surfaced, scrutinized, and retained. This living dialogue is far more effective than static records, as it allows for the continuous updating and contextualization of knowledge in response to new challenges, regulatory changes, and operational shifts. In this way, team design becomes a strategic defense against the silent erosion of expertise that can leave organizations exposed to avoidable risks.

Ultimately, investing in team design as a knowledge preservation strategy is about building organizational resilience. It means recognizing that the greatest threats often arise not from what is known, but from what is forgotten or never shared. By prioritizing teams that embody both breadth and depth of experience, organizations create a robust safety net—one that catches subtle warning signs, adapts to evolving risks, and ensures that critical knowledge endures beyond any single individual’s tenure. This is how organizations move from reactive problem-solving to proactive risk management, turning collective memory into a competitive advantage and a foundation for sustained quality.

Call to Action: Build the Risk Team

Moving from compliance theater to true protection starts with assembling a team designed for cognitive rigor, knowledge depth and psychological safety.

Start with a Clear Charter, Not a Checklist

An excellent risk team exists to frame, analyse and communicate uncertainty so that the business can make science-based, patient-centred decisions. Assigning authorities and accountabilities is a leadership duty, not an after-thought. Before naming people, write down:

the decisions the team must enable,
the degree of formality those decisions demand, and
the resources (time, data, tools) management will guarantee.

Without this charter, even star performers will default to box-ticking.

Fill Four Core Seats – And Prove Competence

ICH Q9 is blunt: risk work should be done by interdisciplinary teams that include experts from quality, engineering, operations and regulatory affairs. ASTM E2500 translates that into a requirement for documented subject-matter experts (SMEs) who own critical knowledge throughout the lifecycle. Map those expectations onto four non-negotiable roles.

Process Owner – The Reality Anchor: This individual has lived the operation in the last 90 days, not just signed SOPs. They carry the authority to change methods, budgets and training, and enough hands-on credibility to spot when a theoretical control will never work on the line. Authentic owners dismantle assumptions by grounding every risk statement in current shop-floor facts.
Molecule Steward – The Patient’s Advocate: Too often “SME” is shorthand for “the person available.” The molecule steward is different: a scientist who understands how the specific product fails and can translate deviations into patient impact. When temperature drifts two degrees during freeze-drying, the steward can explain whether a monoclonal antibody will aggregate or merely lose a day of shelf life. Without this anchor, the team inevitably under-scores hazards that never appear in a generic FMEA template.
Technical System Owner – The Engineering Interpreter: Equipment does not care about meeting minutes; it obeys physics. The system owner must articulate functional requirements, design limits and integration logic. Where a tool-focused team may obsess over gasket leaks, the system owner points out that a single-loop PLC has no redundancy and that a brief voltage dip could push an entire batch outside critical parameters—a classic case of method over physics.
Quality Integrator – The Bias Disruptor: Quality’s mission is to force cross-functional dialogue and preserve evidence. That means writing assumption logs, challenging confirmation bias and ensuring that dissenting voices are heard. The quality lead also maintains the knowledge repository so future teams are not condemned to repeat forgotten errors.

Secure Knowledge Accessibility, Not Just Possession

A credentialed expert who cannot be reached when the line is down at 2 a.m. is as useful as no expert at all. Conduct a Knowledge Accessibility Index audit before every major assessment.

Embed Psychological Safety to Unlock the Team’s Brainpower

No amount of SOPs compensates for a culture that punishes bad news. Staff speak up only when leaders are approachable, intolerant of blame and transparent about their own fallibility. Leaders must therefore:

Invite dissent early: begin meetings with “What might we be overlooking?”
Model vulnerability: share personal errors and how the system, not individuals, failed.
Reward candor: recognize the engineer who halted production over a questionable trend.

Psychological safety converts silent observers into active risk sensors.

Choose Methods Last, After Understanding the Science

Excellent teams let the problem dictate the tool, not vice versa. They build a failure-tree or block diagram first, then decide whether FMEA, FTA or bow-tie analysis will illuminate the weak spot. If the team defaults to a method because “it’s in the SOP,” stop and reassess. Tool selection is a decision, not a reflex.

Provide Time and Resources Proportionate to Uncertainty

ICH Q9 asks decision-makers to ensure resources match the risk question. Complex, high-uncertainty topics demand longer workshops, more data and external review, while routine changes may only need a rapid check. Resist the urge to shoehorn every assessment into a one-hour meeting because calendars are overloaded.

Institutionalize Learning Loops

Great teams treat every assessment as both analysis and experiment. They:

Track prediction accuracy: did the “medium”-ranked hazard occur?
Compare expected versus actual detectability: were controls as effective as assumed?
Feed insights into updated templates and training so the next team starts smarter.

The loop closes when the knowledge base evolves at the same pace as the plant.

When to Escalate – The Abort-Mission Rule

If a risk scenario involves patient safety, novel technology and the molecule steward is unavailable, stop. The assessment waits until a proper team is in the room. Rushing ahead satisfies schedules, not safety.

Conclusion

Excellence in risk management is rarely about adding headcount; it is about curating brains with complementary lenses and giving them the culture, structure and time to think. Build that environment and the monsters stay on the storyboard, never in the plant.

Assessing the Quality of Our Risk Management Activities

The GAMP5 System Owner and Process Owner and Beyond

Defining the accountable individuals in a process is critical. In GAMP5, the technical System Owner role is distinct from the business Process Owner role, which focuses more on the system’s business process and compliance aspects.

The System Owner

The System Owner is responsible for the computerized system’s availability, support, and maintenance throughout its lifecycle. The System owner is the technical side of the equation and is often an IT director/manager or application support manager. Key responsibilities include:

Defining, reviewing, approving, and implementing risk mitigation plans
Ensuring technical requirements are documented
Managing change control for the system
Conducting evaluations for change requests impacting security, maintainability, data integrity, and architecture
Performing system administration tasks like user and privilege maintenance
Handling system patching, documentation of issues, and facilitating vendor support

Frankly, I think too many organizations make the system owner too low level. These lower-level individuals may perform system admin tasks and handle systems patching, but the more significant risk questions require extensive experience.

The System Owner focuses on the technical aspects of validation and ensures adequate procedural controls are in place after validation to maintain the validated state and protect data integrity.

The system owner requires learning and understanding new products and complex system architectures. They are the architect and need to be in charge of the big picture.

The Process Owner

In the context of GAMP5, a Process Owner plays a crucial role in the lifecycle management of computerized systems used in regulated industries such as pharmaceuticals and biotechnology. The Process Owner is ultimately accountable for the system’s implementation, validation, and ongoing compliant use.

I’ve written a lot about Process Owners. This use of process owner is 100% aligned with previous thinking.

Key Responsibilities of a Process Owner

System Implementation and Validation: The Process Owner ensures the system is implemented and validated according to regulatory requirements and company policies. This includes overseeing the creation and maintenance of validation documentation and ensuring the system meets its intended use.
Ongoing Compliance and Maintenance: The Process Owner must ensure the system remains validated throughout its lifecycle. This involves regular reviews, updates, and maintenance activities to ensure continued compliance with regulatory standards.
Data Integrity and Quality: As the data owner maintains the system, the Process Owner is responsible for its integrity, administration, operation, maintenance, and decommissioning. They must ensure that data integrity and quality requirements are met and maintained.
Decision-Making Authority: The Process Owner should be at a level within the organization that allows them to make business and process decisions regarding the system. This often includes roles such as operations director/manager, lab manager, or production manager.
Collaboration with Other Teams: The Process Owner must collaborate with various teams, including Quality (QA), IT, Computer System Validation (CSV), training, HR, system vendors, and system development teams, to ensure that all necessary compliance activities are performed and documented promptly.

Skills and Knowledge Required

Detailed Understanding of the System: The Process Owner should have a comprehensive understanding of the system, its purpose, functions, and use within the organization.
Regulatory Knowledge: A good grasp of regulatory requirements is crucial for ensuring the system complies with all relevant guidelines and standards.
Validation Practices: The Process Owner will sign off on validation documents and ensure that the system is fit for its intended use.

Comparison with the Molecule Steward

While the Molecule Steward, the ASTM E2500 SME role, is not directly equivalent to the GAMP 5 roles, it shares some similarities with both the system owner and process owner, particularly in terms of specialized knowledge and involvement in critical aspects of the system. It’s best to think of the Molecule Steward as the third part of this triad, ensuring the robustness of the scientific approach.

	System Owner	Process Owner	Molecule Steward
Primary Focus	Technical aspects and maintenance of the system	Business process and compliance aspects	Specialized knowledge of critical aspects
Typical Role	IT director/manager or application support manager	Head of functional unit or department using the system	Subject matter expert in specific field
Key Responsibilities	– System availability, support, and maintenance – Data security – Risk mitigation plans – Technical requirements documentation – Change control management – Evaluating change requests	– Overall system integrity and compliance – Data ownership – User requirements definition – SOP development and maintenance – Ensuring GxP compliance – Approving key documentation – User training	– Defining system needs – Identifying critical aspects – Leading quality risk management – Developing verification strategies – Reviewing system designs – Executing verification tests
Expertise	Strong technical background	Business process knowledge	Specialized technical knowledge
Accountability	System performance and security	Business use and regulatory compliance	Critical aspects impacting product quality and patient safety
Involvement in Validation	Focuses on technical validation aspects	Ensures validation meets business needs	Leads verification activities

Comparison of SO, PO and ASTM E2500 SME

Scale of the System

People make the system too small here. This isn’t equipment A or computer system X. It’s the entire system that produces result Y. For example, it is the manufacturing process for DS (or upstream DS), not the individual bioreactors. Lower-level assistants can help with wrangling, but there should be overall accountability. The system, process, and ASTM E2500 SME must have the power in the organization to be truly accountable.

The Role of Quality

The Quality Unit is responsible for ensuring the right process and procedure are in place, that regulatory requirements are met, and that the system is fit for use and fit for purpose. The Quality Unit in GAMP5 is crucial for ensuring the safety, efficacy, and regulatory compliance of pharmaceutical products and computerized systems.

Ensuring Compliance and Product Quality: Quality is vital in ensuring that computerized systems used in pharmaceutical manufacturing meet regulatory requirements and consistently produce high-quality products. The Quality Unit helps organizations maintain high-quality standards in the various processes.
Risk Management: The Quality Unit champions a science-based risk management approach to system validation and qualification. Quality ensures the identification and assessment of potential risks.
Lifecycle Approach: The Quality Unit ensures that validation activities are conducted throughout the system’s lifecycle, from concept to retirement.
Documentation and Traceability: The Quality Unit oversees comprehensive documentation and traceability throughout the system’s lifecycle. Detailed records enable transparency, facilitate audits, and demonstrate compliance with regulatory requirements.
Change Management: The Quality Unit evaluates and controls system changes to ensure that modifications do not compromise product quality or patient safety.
Data Integrity: Quality is crucial in maintaining data integrity and ensuring records’ accuracy, reliability, and completeness.
Supplier and Internal Audits: Quality regularly audits suppliers and internal processes to ensure compliance and quality. These audits help identify gaps and areas for improvement in system development, implementation, and maintenance.

Beyond GAMP5

I consider this the best practice for handling an ASTM E2500 approach.

Common Ownership Challenges

Governance and ownership challenges often arise in an organization for four reasons:

Business stakeholders who resist assuming ownership of their own processes, data and/or knowledge, or have balkanized/siloed accountability
Turf wars or power struggles between groups of stakeholders
Lack of maturity in one or more areas
Resistance to established governance rules

The Business Struggles with Accountability

Processes often have a number of stakeholders, but no apparent owners. This results in opportunity costs as compulsory process changes (e.g. legislative requirements, systems capacity, or company structural changes) or process improvements are not implemented because the business process owner is unaware of the change, or no clear business process owner has been identified which leads to an increase in risk.

Sometimes processes have a number of stakeholders who all think they are the owners of parts of the process or the whole process. When this overlap happens, each supposed owner often identifies their own strategy for the process and issues their own process change instructions to conform to their understanding of the purpose of the business process. These conflicting instructions lead to frustration and confusion by all parties involved.

Lack of accountability in process and system leads to inefficient processes, organizational disharmony, and wasted energy that can be better spent on process improvements.

Turf Wars

Due to silo thinking there can be subdivided processes, owned by different parts of the organization. For example, count how many types of change control your organization has. This requires silos to be broken down, and this takes time.

Lack of Maturity

Governance is challenging if process maturity is uneven across the organization.

Failure to Adhere to Governance

It can be hard to get the business to apply policy and standard consistently.

The role of a data steward

With data integrity on everyone’s mind the last few years, the role of a data steward is being more and more discussed. Putting aside my amusement on the proliferation of stewards and champions across our quality systems, the idea of data stewards is a good one.

Data steward is someone from the business who handle master data. It is not an IT role, as a good data steward will truly be invested in how the data is being used, managed and groomed. The data steward is responsible and accountable for how data enters the system and ensure it adds value to the process.

The job revolves around, but is not limited to, the following questions:

Why is this particular data important to the organization?
How long should the particular records (data) be stored or kept?
Measurements to improve the quality of that analysis

Data stewards do this by providing:

Operational Oversight by overseeing the life cycle through defining and implementing policies and procedures for the day-to-day operational and administrative management of systems and data — including the intake, storage, processing, and transmission of data to internal and external systems. They are accountable to define and document data and terminology in a relevant glossary. This includes ensuring that each critical data element has a clear definition and is still in use.
Data quality, including evaluation and root cause analysis
Risk management, including retention, archival, and disposal requirements and ensuring compliance with internal policy and regulations.

With systems being made up of people, process and technology, the line between data steward and system owner is pretty vague. When a technology is linked to a single system or process it makes sense for them to be the same person (or team), for example a document management system. However, most technology platforms are across multiple systems or processes (for example an ERP or Quality Management System) and it is critical to look at the technology holistically as the data steward. I think we are all familiar with the problems that can be created by the same piece of data being treated differently between workflows in a technology platform.

As organizations evolve their data governance I think we will see the role of the data steward become more and more part of the standard quality toolbox, as the competencies are pretty similar.