Most RFPs contain vague requirements like “must be 21 CFR Part 11 compliant” or “supports electronic signatures.” These phrases sound precise but mean nothing without specifics. What does a compliant electronic signature actually require? How do you verify that mobile workflows maintain the same controls as desktop entries?
The gap between generic RFP language and actual regulatory requirements creates validation chaos. Teams discover missing controls months into implementation. Vendors claim compliance without documentation to support it. Projects stall while IT and Quality scramble to retrofit features that should have been baseline.
This checklist provides testable acceptance criteria across six critical dimensions. Each includes specific technical controls, acceptance tests you can perform during demos, and reference language for RFPs. If your vendor demo checklist doesn’t include these specific tests, you’re buying based on marketing claims rather than verifiable compliance.
The FDA’s 21 CFR Part 11 establishes requirements for electronic records and signatures replacing paper documentation. Electronic signatures must be uniquely attributable to individuals, display printed name + timestamp + meaning, and bind permanently to signed records. Systems must enforce role-based access control (RBAC), least privilege, session timeouts, and prevent administrators from altering signed data without reason-coded QA approval workflows.
Without these controls, you’re creating compliance risk. Inspectors will ask to see signature manifestations on exported records, test whether admins can modify audit trails, and verify that access controls follow separation of duties principles.
Multi-component authentication: User ID + password minimum (§11.200). Support for multi-factor authentication (MFA) recommended for high-risk operations like batch release or deviation approval.
Unique user attribution: Each account maps to exactly one individual. No shared credentials. System enforces unique username policies and prevents concurrent sessions or logs them distinctly.
Signature manifestations: Every signature displays user’s printed name, date/time stamp (to the second), and meaning of signature (e.g., “Calibration Performed,” “Reviewed and Approved”). Signatures are cryptographically or systemically linked to records—cannot be copied, reused, or applied to different records.
Role-based permissions: Granular RBAC where permissions assign to roles, not individual users. Technicians see only their work orders. QA reviewers access deviations and CAPAs. Administrators manage users but cannot modify GxP records without documented reason codes.
Session management: Automatic timeouts after inactivity (typically 15–30 minutes). Users must re-authenticate. Password policies enforce complexity, expiration, history, and lockout after failed attempts.
User lifecycle management: Immediate deactivation of terminated employees. Historical records remain intact and attributable to deactivated accounts.
Sign a work order as User A. Export the record to PDF. Verify the signature manifestation appears with full name, timestamp, and meaning.
Log in as administrator. Attempt to modify the signed record. System must either block the modification or require a reason code from a controlled list with QA approval workflow before proceeding.
“Platform provides uniquely attributable electronic signatures with manifestation (printed name, timestamp, meaning) permanently bound to records. Includes configurable multi-factor authentication, granular role-based access controls, automatic session timeouts, and prevents administrative modification of signed records without reason-coded QA approval.”
FDA’s data integrity guidance emphasizes ALCOA+ principles—data must be Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available. Audit trails enforce these principles by capturing every change to GxP-relevant data with immutable, tamper-evident records.
Incomplete audit trails are a major citation risk. Recent warning letters highlight missing before/after values, uncontrolled reason codes (free-text instead of controlled lists), and audit logs administrators can modify or delete. Your system must log who, what, when, where, and why for every data change—with no hard deletion, only inactivation with documented reasons.
Complete logging: Capture user ID, specific action (field modified, record created, workflow state changed), date/time stamp with precision to the second and time zone, before/after values for modifications, and reason codes from controlled lists (not free-text) for changes to signed records or critical parameters.
Tamper-evident design: Audit logs cannot be modified or deleted by anyone, including system administrators. No “purge audit logs” function exists. If storage approaches capacity, system alerts and prevents new transactions rather than overwriting logs.
Synchronized timekeeping: System time synchronized to validated NTP (Network Time Protocol) server ensuring accurate, consistent timestamps across all records and sites. Users cannot modify system time.
Retention alignment: Audit trails retained at least as long as the records they document—typically 5+ years for manufacturing records, longer for device master records.
Scheduled reviews: System supports audit trail review workflows with designated QA roles, date range selection, and evidence of review completion (signed review records showing findings and disposition).
Create and complete a work order. Modify a field in the completed record. System should prompt for a reason code from a controlled list.
Export the audit trail. Verify it shows: original creation (user, timestamp), completion (user, timestamp), modification (user, timestamp, field changed, old value, new value, reason code).
Log in as administrator. Attempt to delete or modify an audit trail entry. System must prevent this action entirely.
“Tamper-evident audit trails capturing who/what/when/why for all GxP data changes. Logs include before/after values, reason codes from controlled lists, and time stamps synchronized to validated NTP server. System prevents audit log modification or deletion by any user role. Includes scheduled QA review workflows with documented evidence.”
The FDA’s Computer Software Assurance guidance encourages risk-based assurance and critical thinking—focusing validation effort on critical functions rather than exhaustive testing of every feature. When vendors provide comprehensive validation packages aligned to GAMP 5 guidelines, you can leverage their testing and documentation to materially reduce internal validation effort compared to building protocols from scratch.
Without vendor-supplied validation, you’re writing test scripts from scratch, documenting every requirement-to-feature mapping, and performing extensive regression testing with each upgrade. Purpose-built GMP platforms provide pre-written IQ/OQ/PQ protocols, traceability matrices, and release notes supporting targeted regression—transforming months of validation into weeks.
Complete validation package: Functional specifications, design specifications, pre-written IQ/OQ/PQ test scripts with expected results and acceptance criteria, requirements traceability matrices mapping regulatory requirements to features and test cases, test execution records proving vendor testing, and validation summary reports.
GAMP 5 alignment: Category 4 (configured products) documentation where vendor supplies core platform validation and you validate configurations, integrations, and site-specific workflows. Avoid Category 5 (custom applications) requiring you to validate everything.
Release notes for upgrades: Detailed documentation of all changes between versions—features, bug fixes, security patches. Notes indicate which changes affect validated functionality, enabling targeted regression testing rather than full revalidation.
Reference customers: Pharmaceutical manufacturers who’ve validated the system using vendor documentation. Request contact with three references to verify actual timelines and validation effort.
Request the complete validation package before contracting. Review the IQ protocol—does it include test cases for infrastructure, security, backup/recovery? Or just software installation?
Examine the OQ protocol. Are there test scripts for every critical GMP function (electronic signatures, audit trails, calibration calculations, change control)? Do scripts include expected results?
Check three consecutive release notes. Do they clearly document all changes? Do they indicate which changes require regression testing?
“Complete GAMP 5-aligned validation package including pre-written IQ/OQ/PQ protocols, requirements traceability matrix, functional and design specifications, test execution records, validation summary reports, and release notes documenting all changes to support targeted regression testing. Vendor provides pharmaceutical customer references who’ve completed validation using supplied documentation.”
While Part 11 addresses audit trails and signatures, it doesn’t comprehensively cover cybersecurity or mobile/cloud deployment. Pharmaceutical manufacturing has Wi-Fi dead zones—cleanrooms, equipment rooms, utilities—where technicians must capture calibration and maintenance data on-site. Mobile convenience cannot compromise GMP controls.
Cloud deployments introduce infrastructure qualification challenges: maintaining validated state through provider updates, ensuring geographic data residency, and proving disaster recovery capabilities. Systems need encryption at rest and in transit, independent security certifications (SOC 2 Type II, ISO 27001), and mobile offline workflows preserving Part 11 controls when disconnected.
Data encryption: AES-256 or equivalent for data at rest. TLS 1.2 or higher for data in transit (web browsers, mobile apps, APIs). Encryption keys managed through secure key management systems, not hard-coded.
Security certifications: SOC 2 Type II (demonstrating controls operated effectively over 6+ months) and ISO 27001 (comprehensive information security management). Request current certificates—verify they’re not expired.
Mobile offline integrity: When devices operate offline, data stored encrypted locally. Queue-based synchronization preserves chronological order and detects conflicts. Audit trails capture offline actions with device timestamps, sync events, and server-validation timestamps. Electronic signatures offline meet same attribution and manifestation requirements as online.
Cloud infrastructure qualification: Vendor provides cloud qualification documentation covering servers, networks, storage, security controls. Change control for cloud provider updates maintains validated state. Geographic redundancy, automated failover, tested disaster recovery procedures with documented RTO (Recovery Time Objective) and RPO (Recovery Point Objective).
Vulnerability management: Regular security assessments including penetration testing, vulnerability scanning, and documented patching cadence. Security bulletins when vulnerabilities are discovered and remediated.
Put a demo tablet in airplane mode. Create a work order, capture data, provide electronic signature. Verify data stores locally. Reconnect and confirm sync with complete audit trail showing offline capture time, sync event, and server timestamp.
While device is offline editing a work order, modify the same work order on desktop. Reconnect mobile device. System should detect conflict and require resolution.
Request current SOC 2 Type II and ISO 27001 certificates. Verify issue dates and that they’re not expired.
“Encryption at rest (AES-256) and in transit (TLS ≥ 1.2). SOC 2 Type II and ISO 27001 certifications with evidence of regular security assessments. Mobile offline execution with encrypted local storage, queue-based sync preserving audit trail integrity, and Part 11-compliant electronic signatures. Cloud deployment with infrastructure qualification documentation, validated change control for provider updates, and disaster recovery capabilities with documented RTO/RPO.”
Modern pharmaceutical manufacturing requires data flow between maintenance systems and quality management systems (QMS), laboratory information systems (LIMS), manufacturing execution systems (MES), and enterprise resource planning (ERP). When the CMMS reports an out-of-tolerance (OOT) instrument to LIMS, blocking sample assignment, both systems must log the transaction with traceable correlation. Each integration point is a potential compliance gap if not properly controlled.
Silent data loss or integration failures without alerting create serious audit findings. Inspectors will ask how you ensure calibration status accurately flows to connected systems and what happens when integrations break.
Bidirectional audit trails: Both systems log each transaction. When CMMS sends equipment status to LIMS, both systems record the handshake. If LIMS sends calibration request to CMMS, both log the exchange.
Correlation IDs: Each transaction carries a unique correlation ID appearing in both systems’ audit logs. Investigators can trace data flow: “LIMS rejected sample at 14:32:18 because CMMS reported OOT status—correlation ID 7B3F9A.”
Error handling and alerting: When integrations fail (network issues, system downtime, validation errors), both systems log failure and alert designated users. No silent data loss. Failed transactions trigger automated notifications and may halt dependent processes until resolved.
Secure API authentication: OAuth 2.0, service accounts with minimal necessary permissions, or API keys with rotation policies. Credentials stored securely—not hard-coded in configurations.
Change control coordination: Updates to either system require integration impact assessment. Changes affecting integration points follow coordinated change control between system owners.
Data validation at boundaries: Integrations validate data types, required fields, business rules before accepting transactions. Invalid data rejected with clear error messages logged in both systems.
Request demonstration or architecture diagrams showing integration with your QMS, LIMS, or MES systems. Are there pre-built connectors or custom development required?
Simulate an integration failure during demo (if possible). How does the system respond? Are users alerted? Is failure logged with sufficient detail?
Ask about API versioning. When APIs update, how are breaking changes managed? What notice do customers receive? How do you maintain validated state through API changes?
“Bidirectional audit trails with correlation IDs for all integration transactions. Automated alerting on integration failures with transaction logging in both systems. Secure API authentication (OAuth 2.0/service accounts). Pre-built connectors for common GxP systems (QMS, LIMS, MES, ERP) with documented integration validation approach and coordinated change control procedures.”
Generic vendor claims like “Part 11 compliant” or “validates easily” don’t help you make decisions. Score vendors on specific, testable criteria using a 0-3 scale:
Document your scoring rationale in demo notes. When vendors dispute scores, reference specific acceptance tests they passed or failed.
New Zealand Pharmaceuticals (NZP), part of the global ICE Pharma group, needed to modernize its maintenance and calibration operations. Their proprietary system was unreliable, provided limited reporting, and created audit risks as compliance demands increased.
Since implementing Blue Mountain in 2018, NZP has:
The distance between generic RFP requirements and these specific, testable criteria determines whether you’re making an informed decision or hoping vendor marketing aligns with regulatory reality.
Organizations evaluating vendors using acceptance tests consistently report faster validation timelines, fewer post-implementation surprises (discovering gaps during demos, not during validation), stronger audit performance, and lower total cost by avoiding custom development and revalidation cycles.
Actual validation effort varies by system complexity, risk classification, configuration scope, and internal quality processes.
Purpose-built GMP platforms like Blue Mountain RAM address these requirements out-of-box because they’re designed specifically for regulated manufacturing. Generic systems can be customized to meet requirements—but customization creates validation burden, upgrade friction, and long-term technical debt.
The choice isn’t just about features. It’s about whether compliance is embedded in the platform or something you build on top of it.
Use this checklist during RFP development and vendor demonstrations. Score vendors on testable criteria, not marketing promises.
Schedule a RAM platform demonstration → where we’ll walk through every requirement with live system examples you can test yourself.
Or calculate your potential ROI → from reducing validation timelines, improving audit readiness, and eliminating compliance retrofits.
This post was originally published in March, 2015. It was updated December 2025 to reflect changes in GMP expectations, FDA guidance (including Computer Software Assurance), cloud deployment models, and how life sciences teams now evaluate EAM/CMMS platforms.
