Pharmaceutical Software Development Company

Part 11 and Annex 11 controls

US 21 CFR Part 11 applies to electronic records kept under FDA record requirements, and EU GMP Annex 11 to computerized systems used in GMP-regulated activities. FDA's scope and application guidance reads Part 11 narrowly and keeps predicate rules enforced, so design starts from the records those predicate rules require.

Some Part 11 controls are procedural rather than technical, such as determining that people have the education, training and experience for their tasks and keeping written policies that hold individuals accountable for their electronic signatures; those stay with your organization.

From Part 11: "Record changes shall not obscure previously recorded information." From Annex 11: "For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed." Our reference design adds an audit-trail review screen.

For data integrity, PIC/S guidance asks companies to "ensure that data is attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available", known as ALCOA+. FDA's drug CGMP guidance uses the five-letter ALCOA, and neither appears in Part 11 or the Annex 11 in force. The draft revision cites ALCOA+, so for now it is our design checklist, not a legal test.

How validation works: GAMP 5, risk-based assurance and evidence

ISPE's GAMP 5 guide, industry guidance rather than a regulation, sorts software into categories 1, 3, 4 and 5, with validation effort growing toward custom code. Your QA team confirms each component's category.

Test depth follows risk. FDA's Computer Software Assurance guidance describes that approach for device makers' production and quality system software: "This guidance provides recommendations regarding computer software assurance for computers or automated data processing systems used as part of production or the quality management system for medical devices." Applying it to drug GMP systems is our interpretation by analogy. The drug-side anchor is ICH Q9(R1): "The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk." We propose a test method per feature, and your QA team approves the split.

On pharma engagements, each release ships with a validation-ready pack: requirement IDs traced to design, code and tests, functional and design specifications, risk input per feature, automated test evidence and a generated trace matrix.

Who does what (R responsible, A accountable, C consulted, I informed):

With a pharma-tech product vendor, the split is usually drawn one level up: the vendor is itself the supplier its customers qualify, so it takes the regulated user's side of this table for its product, with us as its development partner.

Validation also fits sprints. ISPE's GAMP 5 page describes the Second Edition as "emphasizing that the GAMP specification and verification approach is not inherently linear but also fully supports iterative and incremental methods".

After go-live, changes run through your change control, and Annex 11 adds "Computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP." The category 4 row above covers regression testing on vendor releases.

What your QA team receives for supplier assessment

On pharma engagements we support supplier assessment with a pack:

• A written description of our delivery lifecycle, from requirements to release and change control
• Project evidence as produced, such as traceability, test results and release notes
• Named team members, their roles and least-privilege access to your environments
• Our security posture: no ISO 27001 certificate and no SOC 2 report, plus the controls we apply, listed below
• Disclosure of any subcontracting or third-party hosting before signature, for your approval
• On request, a hosted supplier audit (remote or on site) and support during a regulatory inspection
• A documented exit plan

Annex 11 puts that assessment on the regulated user: "The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately."

We offer a quality agreement next to the master services agreement that assigns validation, change control, incident notification, subcontracting approval and audit rights. Annex 11 section 3.1 requires formal agreements with third parties that provide, configure, validate or maintain a computerized system, and EU GMP Chapter 7 covers written contracts for outsourced GMP activities. FDA's Part 11 questions and answers recommend a written agreement with IT service providers in clinical investigations.

AI agents and LLMs under GxP

We build AI agents and generative AI features with the GxP impact, the human checkpoint and the retained evidence settled before any output reaches a GxP record. The non-binding EMA and FDA AI principles likewise assess the whole system, human-AI interaction included.

The draft EU GMP Annex 22 covers only static, deterministic AI models in critical GMP applications and states "Following the above, the document does not apply to Generative AI and Large Language Models (LLM), and such models should not be used in critical GMP applications." The EMA workshop page adds: "EMA is still considering the implications of the stakeholder consultation results." Until a text is adopted, we keep GenAI out of critical GMP decisions.

FDA's draft guidance on AI for regulatory decision-making proposes a credibility assessment tied to a model's context of use, and "the use of AI for the purposes of drug discovery is not in the scope of this guidance". EU AI Act classification turns on Article 6 and Annexes I and III, so we assess each feature with your counsel (see our AI Act classification guide). Pharmacovigilance AI designs are reviewed against the seven principles of the CIOMS Working Group XIV report:

• Risk-based approach
• Human oversight
• Validity and robustness
• Transparency
• Data privacy
• Fairness and equity
• Governance and accountability

Integrations and data standards

Pharma landscapes can include Veeva Vault applications, Salesforce Life Sciences Cloud, SAP S/4HANA, LIMS, EDC and safety databases. We work through each vendor's documented interfaces and hold no Veeva, Salesforce or SAP partner status.

Security and privacy for pharma data

HIPAA reaches a pharmaceutical manufacturer through data it handles for a covered entity. Under 45 CFR 160.103, covered entities are health plans, clearinghouses and providers that transmit health information electronically in covered transactions, so a manufacturer is not one. A business associate acts "On behalf of such covered entity or of an organized health care arrangement (as defined in this section) in which the covered entity participates".

In the EU, GDPR makes health data a special category, processed only under an Article 9 exception, and a vendor processing it needs an Article 28 contract. Under NIS2, manufacturers of basic pharmaceutical products and preparations and medicinal product research entities are Annex I health types, and most device makers are Annex II types. Scope usually starts at medium size, but Article 2(2) and 2(3) cover some Annex I and II entities regardless of size, for example where disruption could significantly affect public health.

Related guides and services: NIS2 for software suppliers, NIS2 outsourcing, HIPAA development costs, EHDS conformity assessment and compliance engineering.

Controls we apply on pharma engagements: least-privilege access, no production patient data in development or test, encryption in transit and at rest, EU or US data residency, secrets management, security testing before release and a software bill of materials.