Category: Digital Compliance & Data Integrity

DIGITAL COMPLIANCE

A regulated customer is not buying software alone. It is deciding whether the platform, the supplier and the available evidence can support a controlled GxP process.

That distinction changes the sales conversation. Claims such as “validated,” “Part 11 compliant” or “built for life sciences” may attract attention, but they do not answer the questions a Quality, Regulatory, IT or business owner must resolve before approving a system for regulated use.

The decisive question is not whether a SaaS product has compliance features. It is whether the customer can define its intended use, understand the risks, configure the system appropriately, obtain proportionate assurance and maintain control throughout the lifecycle.

1. A clear intended use and regulated boundary

Before assessing features, the customer needs to know what the platform will do in its own process. Will it create, modify, approve, retain or transmit regulated records? Will it support a quality decision? Could a failure affect product quality, patient safety, data integrity or regulatory evidence?

The same platform can have different risk profiles in different implementations. A tool used for informal collaboration is not equivalent to the same tool used to approve deviations, manage training records or control manufacturing data. A credible supplier helps the customer define that boundary instead of making a blanket compliance claim.

2. A defensible allocation of responsibilities

In SaaS, control is shared. The supplier controls the underlying product, infrastructure, release process and many security safeguards. The customer controls intended use, configuration choices, user access, procedures, training and the decision to release the system for use.

Regulated customers therefore expect a responsibility model that makes this division explicit. They need to understand who performs testing, reviews audit trails, approves changes, manages incidents, retains records, verifies backups and evaluates new releases. Ambiguity here becomes a validation gap later.

3. Evidence that supports risk-based assurance

The evidence package should help the customer reach a justified conclusion without recreating the supplier’s entire development lifecycle. Useful evidence commonly includes:

• a current system description, architecture and data-flow overview;
• documented software development and quality practices;
• requirements or feature specifications traceable to testing;
• release notes and a controlled change-management process;
• security, availability, backup and recovery information;
• incident, problem and vulnerability-management processes;
• evidence for configurable controls such as access, audit trails and electronic signatures;
• data export, retention and termination provisions;
• independent certifications or reports, where relevant, with their scope clearly stated.

More documentation is not automatically better. The objective is sufficient evidence for the actual risks and intended use. FDA’s final Computer Software Assurance guidance encourages a risk-based approach for production and quality-management-system software used in medical device manufacturing. Its scope matters: it should not be represented as a universal rule for every GxP application. Its underlying discipline, however—focus assurance effort on the functions and failures that matter—is highly relevant to sound validation strategy.

4. Controls that work in the customer’s configuration

A feature list is not proof of effective control. The customer needs to evaluate how controls behave in the proposed configuration and business process.

• Access: Can privileges be limited by role and reviewed over time?
• Audit trails: Are relevant actions captured, time-stamped, retained and available for meaningful review?
• Records: Can complete, accurate and readable copies be produced throughout the retention period?
• Electronic signatures: Where signatures are used, are identity, intent and record linkage appropriately controlled?
• Data integrity: Are changes attributable, original information preserved and exceptions detectable?
• Workflow: Does the configuration enforce required sequencing, review and approval steps?

For FDA-regulated electronic records and signatures, the applicable requirements are set out in 21 CFR Part 11. In the EU GMP context, EudraLex Volume 4, Annex 11 addresses computerized systems. Applicability depends on the regulated process, record and jurisdiction; it cannot be established by marketing language alone.

5. Lifecycle control after go-live

Initial validation is only the beginning. SaaS products evolve continuously, while regulated customers must maintain a controlled state. Customers will look for advance notice of material changes, meaningful release information, a way to assess impact before deployment, and clear handling of emergency fixes.

The strongest operating model distinguishes changes that require customer assessment from changes that do not affect regulated use. It also defines periodic review, user-access review, audit-trail review where appropriate, incident escalation, supplier performance monitoring and business-continuity testing.

6. Transparency about limitations

Trust increases when a supplier states what the platform does not control. A defensible position may say that the product provides technical capabilities supporting Part 11 or Annex 11 requirements, while the customer remains responsible for determining applicability, validating its intended use and operating the system under controlled procedures.

This is stronger than declaring the platform “compliant” in isolation. Compliance is achieved through the combined system of technology, configuration, people, procedures and evidence.

Questions regulated buyers will ask

• Which GxP processes and records will this system support?
• What failures could affect product quality, patient safety, data integrity or a regulatory decision?
• What assurance has the supplier performed, and what evidence is available to customers?
• Which controls are standard, configurable or dependent on customer procedures?
• How are releases, incidents and security vulnerabilities communicated?
• Can records and audit trails be exported in usable form and retained for the required period?
• What happens to data and evidence if the service ends?
• If AI-enabled functions are used, how are intended use, human oversight, changes and output risks controlled?

The commercial advantage of being assessment-ready

A supplier that can answer these questions early shortens diligence, reduces repetitive questionnaires and gives regulated buyers a clearer path to approval. The goal is not to promise zero risk. It is to show that risks are understood, responsibilities are defined and the evidence supports the claims being made.

For SaaS companies entering life-science markets, the right starting point is a gap assessment of the product, evidence package, supplier controls and customer-facing claims. For regulated companies selecting a platform, it is an intended-use and risk assessment that determines what must be verified before approval.