Skip to main content
21 CFR Part 11 is a regulation established by the U.S. Food and Drug Administration (FDA) that sets the guidelines for the use of electronic records and electronic signatures in the pharmaceutical, biotechnology, medical device, and other FDA-regulated industries.

​
Seal’s approach to 21 CFR Part 11

Seal is purpose-built for GxP-regulated environments—including GMP, GLP, and GCP. Compliance is not a bolt-on feature; it is embedded in the platform’s architecture. Pharmaceutical, biotech, and medical device companies trust Seal to manage their regulated records, electronic signatures, and audit trails.
Key compliance capabilities built into Seal:
  • Immutable, time-stamped audit trails for all record changes
  • Two-component electronic signatures with re-authentication at signing
  • Role-based access control with granular permissions
  • Complete record retention with full audit history preserved
  • SSO integration with MFA inheritance from enterprise identity providers
  • Session timeouts with 15-minute default for Part 11 compliance
The sections below detail how Seal satisfies each requirement of 21 CFR Part 11.

​
Subpart B - Electronic records

11.10 Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records, and to ensure that the signer cannot readily repudiate the signed record as not genuine.
11.10a Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
Seal is a closed system as defined by the FDA (11.3(b)(4)). Access is restricted to authorized individuals designated by the customer’s administrators, and the environment is controlled by persons responsible for the content of electronic records. Seal maintains SOC 2 Type II certification, and the platform is hosted on Google Cloud Platform (also SOC 2 Type II, ISO 27001 certified).
  • Confidentiality: Records are accessible only to authorized users. Granular sharing rules and role-based permissions ensure data is visible only to those who need it.
  • Authenticity: Every record has a single, immutable author recorded at creation. This cannot be changed throughout the record’s lifecycle.
  • Integrity: All record changes are tracked in a tamper-proof audit trail with server-generated timestamps. Archived records remain in the database with complete history preserved—no data is ever permanently deleted. All data is encrypted in transit (TLS 1.2+) and at rest (AES-256).
11.10b The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency.
Records can be exported as PDF documents that include the complete audit trail, all signatures, timestamps, and reviewer comments. API access is also available for programmatic data extraction. Exports are suitable for regulatory inspection and submission.
11.10c Protection of records to enable their accurate and ready retrieval throughout the records retention period.
All records are retained for a minimum of three years beyond the subscription period. Archived records remain fully accessible in the database with their complete audit trail. Data is stored with automatic backups and geographic redundancy to ensure availability.
11.10d Limiting system access to authorised individuals.
Every user authenticates with a unique email and password. Organizations can enforce Single Sign-On (SSO) via Microsoft Azure AD, Okta, or other enterprise identity providers. User accounts can be provisioned, modified, and deactivated instantly by organization administrators.
11.10e Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information.
Seal automatically generates immutable, server-timestamped audit logs for every action—including record creation, edits, status changes, signatures, and access events. Previous versions are preserved in full; no information is ever obscured or overwritten. Audit logs are retained for the lifetime of the record and cannot be modified by any user.
11.10f Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.
Seal enforces workflow sequencing through configurable review requirements, approval chains, and status transitions. Records cannot progress to subsequent stages until all required steps are completed and approved.
11.10g Use of authority checks to ensure that only authorised individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.
Role-based access control governs all system actions. Permissions are configurable at the organization, workspace, and record level. Electronic signing rights are explicitly assigned—users without signing permissions cannot execute signatures.
11.10h Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction.
Input validation rules can be configured for data fields, including format checks, range limits, and required field enforcement. Integration inputs from external systems are validated against defined schemas before acceptance.
11.10i Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.
Seal’s engineering and product teams have extensive experience in regulated software development for pharmaceutical, biotech, and medical device companies. The platform is developed following GAMP 5 principles with formal change control, peer code review, and comprehensive automated testing at unit, integration, and end-to-end levels.
11.10j The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.
Seal provides SOP templates for electronic signature policies as part of the validation package. The platform enforces an acknowledgment workflow requiring users to confirm the legal equivalence of their electronic signature before first use.
11.10k Use of appropriate controls over systems documentation including: Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance.
Comprehensive documentation—including user guides, administrator manuals, API reference, and release notes—is maintained in a version-controlled documentation portal. All documentation changes are tracked with full revision history.
Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt.
This section does not apply. Seal operates exclusively as a closed system with authenticated access controlled by customer administrators.
Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:
  • The printed name of the signer
  • The date and time when the signature was executed
  • The meaning (such as review, approval, responsibility, or authorship) associated with the signature
Every electronic signature in Seal displays the signer’s full name, the exact date and time of signing (server-generated), and the meaning of the signature (e.g., “Approved,” “Reviewed,” “Authored”). This information is displayed in the application and included in all PDF exports.
The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record.
Signatures are immutably recorded in the audit log and cannot be modified, removed, or transferred to another record. Signature data is included in all human-readable exports.
Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.
Electronic signatures in Seal are permanently linked to their associated records through immutable database associations. Signatures cannot be excised, copied, or transferred to another record.

​
Subpart C - Electronic signatures

11.100a Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.
Each user has a unique account tied to their email address. Signatures are linked to this unique identity and cannot be shared or reassigned.
11.100b Before an organisation establishes, assigns, certifies, or otherwise sanctions an individual’s electronic signature, or any element of such electronic signature, the organisation shall verify the identity of the individual.
Seal supports Two-Factor Authentication (2FA) via time-based one-time passwords (TOTP). SSO users inherit MFA requirements from their enterprise identity provider. Identity verification is enforced at login and again at the point of electronic signing.
11.100c Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures.
The submission of certifications to the FDA is the responsibility of the regulated organization. Seal provides template language and guidance to support customers in preparing these certifications.
11.200a Electronic signatures that are not based upon biometrics shall employ at least two distinct identification components such as an identification code and password.
Seal implements two distinct identification components:
  • Component 1 (Identification Code): The user’s unique email address, verified at login and re-verified at the point of signing.
  • Component 2 (Password): The user’s password, which must be re-entered at the point of signing to confirm identity.
For SSO users, re-authentication is performed via the organization’s Identity Provider (e.g., Microsoft Azure AD, Okta) at the point of signing, inheriting any MFA requirements configured by the organization.
11.200a-i When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components.
The first signature in a session requires full re-authentication (both email and password or SSO re-authentication). Subsequent signatures within the same continuous period of controlled system access may use streamlined authentication. Session timeouts default to 15 minutes to meet Part 11 requirements.
11.200a-3 Be administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals.
Passwords are stored using industry-standard cryptographic hashing. Seal employees do not have access to user passwords. Compromising a signature would require access to both the user’s email account and their password.
11.200b Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.
Biometric signatures are not used on the platform.
11.300a Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.
Email addresses are globally unique. The system prevents duplicate accounts and enforces unique credentials for every user.
11.300b Ensuring that identification code and password issues are periodically checked, recalled, or revised (e.g., to cover such events as password ageing).
For SSO organizations, password aging and complexity policies are enforced by the enterprise Identity Provider and inherited by Seal. For organizations using Seal’s native authentication, administrators can require password resets and enforce 2FA. Organizations should document password aging requirements in their SOPs and can migrate to SSO for centralized policy enforcement.
11.300c Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices.
Organization administrators can immediately revoke user access, reset passwords, and deactivate 2FA devices. Lost or compromised credentials can be invalidated within seconds.
11.300d Use of transaction safeguards to prevent unauthorised use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorised use.
Seal implements rate limiting on authentication attempts, automatic account lockout after repeated failures, and real-time alerting for suspicious login patterns. IP-based access restrictions can be configured for additional security.
11.300e Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly.
2FA devices are validated at enrollment and verified at each use. Failed or compromised devices can be immediately deactivated and replaced by organization administrators.