Autolomous designs all of its products and systems to help clients meet their regulatory and accreditation requirements by means of consultative design, configuration and validation processes and this includes requirements for electronic signatures that are applicable to the Advanced Therapies sectors in the UK, EU, US and worldwide.

The de facto standard is the US Food and Drug Administration’s Title 21 Code of Federal Regulations, Subchapter A, Part 11, which deals with electronic records and signatures and, in practice, compliance with these requirements should also deliver compliance with requirements in other countries.

However, whilst system design can support compliance and make it more likely than not that signatures and records meet these requirements, many other factors are just as important. These will include validation procedures, documentation, training, system security features and checks, system processes and procedures, configuration choices and other factors.

This means that a regulated organisation needs to think carefully about how any electronic system that supports manufacture, distribution or clinical use within a trial of a medicinal product is designed, configured, validated and used before the system can be used.

Autolomous is committed to working with all relevant stakeholders to ensure that appropriate choices are made and procedures are followed at every stage so that the finished systems and records generated will meet their requirements for the lifetime of the systems and records.

The table below indicates how this can be ensured and may be of use to organisations considering electronic solutions to replace or supplement paper-based processes.

General
Part 11 ref.	Requirement	Comment
11.10 (a)	The system is validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. The scope of validation includes tests and checks, which demonstrate compliance with all applicable parts of FDA Title 21 CFR Part 11.	The applications and platform go through validation testing following GxP and GAMP5 principles. Test records are retained. To comply with the regulation, users must also perform validation testing once installed and configured (Performance Qualification).
11.10 (i)	Personnel who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.	Autolomous operates an employee training and development programme that includes all relevant knowledge and skills. Employee recruitment includes checks against suitable education, training & experience selection criteria and competence gaps are addressed via initial and ongoing training. Autolomous provides training, advice and ongoing support for system maintenance tasks performed by the customer such as user account administration and maintains the platform under documented agreements.
Documentation
11.10 (k) (1)	Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance.	Documented information including the AutoloMATE User Guide and ongoing support are made available to help users learn how to use and maintain the system.
11.10 (k)(1)	Controls are in place to ensure only authorised users see (have access to) documentation.	Autolomous maintains appropriate security controls to restrict access to documentation relevant to system security and electronic signatures both internally and for documentation shared with customers. It is the customer’s responsibility to implement similar controls for documentation that they control.
11.10 (k)(2)	System documentation is produced and maintained under a revision control procedure to maintain an audit trail that documents time-sequenced development and modification of systems documentation.	Documentation is produced and maintained under a strict revision control procedure and is controlled in our Quality Management System so that there is a complete audit trail of development and modification.
System security
11.10 (d)	System access is limited to authorised individuals.	Access to systems requires unique accounts, user names and passwords or passphrases at all levels.  The core application (AutoloMATE) has rich access management functionality based on role-based or individual appropriate permissions. Configuration choices are a key design consideration.
11.10 (g)	Authority checks are in place to ensure that only authorized 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.	Access to each area of system functionality and data is provided to individuals and groups via permissions assigned by system administrators. Electronic signatures may only be performed by individual account holders and no individual can alter data associated with an electronic signature.
11.10 (d)	An approved procedure which describes the administration of security is available which includes: Add new user, assign user to groups/roles, change user privileges, deactivate user, force reissue of password.	System Administrator guidance documents describing how to perform these tasks are provided by Autolomous and training is given. It is the responsibility of the customer to define and document responsibilities and approvals and change processes.
11.10 (d)	To ensure the uniqueness of user IDs, users should never be deleted from the system. Instead, the IDs should be deactivated and retained.	User accounts can only be made inactive within the application; they cannot be deleted. The system audit trail logs all activation and deactivation events.
Operational checks
11.10 (f)	Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.	The AutoloMATE eBMR workflows are configured as per customer specifications. The workflow sequence is enforced by the system to ensure individuals are mandated to complete it as per the customer’s pre-established order.
Device checks
11.10 (b)11.10 (e)	Accurate copies of electronic records (including audit trails) can be made in both paper and electronic form.	AutoloMATE allows users to export their manufacturing process and data in PDF format in addition to the available audit trails, so PDF or hard copies can be generated. Customers should verify that permanent printed copies can be generated in their printing environment.
11.10 (b)	An approved procedure, which describes the process of making these copies, is available.	The procedures for generating and downloading copies of records from the system are described in system user documentation. Access to records is controlled so that only authorised individuals may access the required functionality and data. Backups are taken utilising a fast, affordable and reliable Continuous Data Protection and point-in-time recovery solution.
11.10 (e)	Electronic records (including audit trails) are backed up on a regular basis.	All backups are by default stored and encrypted in remote and secure data facilities with logging and failure alerting. Reports can be provided to customers when/as needed.
11.10 (c)	An approved procedure, which describes the backup process, is available.	An approved procedure is in place and will be regularly reviewed in line with Autolomous’ ISMS and ISO 27001:2013 requirements.
11.10 (c)11.10 (e)	Protection of records (including audit trails) to enable their accurate and ready retrieval throughout the records retention period.	No records may be deleted from Autolomous software products and records and audit trails are protected and retrievable as true, accurate copies throughout the retention period. The procedures for downloading copies of records from the system are described in the system documentation.
11.10 (c)	An approved procedure, which describes the archive and restore process, is available.	An approved procedure for backup and restore operations is in place and will be regularly reviewed in line with ISO 27001:2013 requirements. It is the customer’s responsibility to define and maintain procedures and responsibilities that determine which individuals are authorised to request restore operations. If a customer should choose to archive records, a customer-specific procedure would need to be agreed upon.
11.10 (c)	The retention period for the electronic records created by the system are clearly defined.	The default retention period for all data and records is specified by individual customers and is defined in individual agreements. Customers may choose to discard electronic records at the end of this period in favour of PDF or hard copy paper records if they choose to archive records in this way.
Audit trails
11.10 (e)	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. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for review and copying by the regulatory body.	AutoloMATE has rich audit trail functionality as standard.Audit trails are automatically generated and time-stamped by the system.The system retains previously recorded and modified information so that it is clear what was recorded by whom and when.The audit trail information is retained for the same period as the data to which it applies and can be shown to inspectors or auditors or made available as true copy records.Logical rules that modify data are not used and data would only be deleted at the end of the retention period as described above.
11.10 (e)	Each audit trail entry consists of:Operator IDAction performedNew and previous value if the action is modified or updatedTime and date action occurred	Each audit trail consists of operator ID, action performed, new and previous values and time/date stamping.
11.10 (e)	An approved procedure, which describes the method of maintaining the accuracy of system clocks, which perform time stamping, is available. This should include the regular synchronisation of system, clocks if appropriate.	All system date/time functionality is derived from the system server clocks and is described in host provider documentation. This makes use of industry-standard UTC time and automatic synchronisation to reference clocks that occurs at least daily.
Electronic signatures and general requirements
11.10 (j)	A written policy is available that holds individuals accountable and responsible for actions initiated by their electronic signature in order to deter record and signature falsification. Records are available to confirm that all electronic signature users have read and understood this policy.	Wherever required, electronic signatures are enforced by the system. It is the customer’s responsibility to write and distribute a policy to their users of the system that makes it clear that their electronic signature is being recorded when they execute an electronic signature and that they are accountable and responsible for the actions they are signing to attest they have completed. The policy should include a statement that, by completing each electronic signature, the user is also confirming that they have read and understood the policy.
11.50 (a)	Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:(1) The printed name of the signer;(2) The date and time when the signature was executed; and(3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.	The electronic signature record includes these elements (requirement 3 is met by virtue of the context of the record – i.e. the step with which it is associated).
11.50 (b)	The items in 10.50 (a) 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 (such as electronic display or printout).	This data and information are human-readable within the application.
Signature record linking
11.70	Each electronic signature is linked to its associated electronic record to ensure that the signature cannot be excised, copied, transferred or in any way falsified by ordinary means. There must be no access to electronic signatures other than read only via the standard system functions.  Any other access to records containing signatures must be restricted.  Any legitimate access to such records (e.g. database administrator) must be restricted by a formal written procedure.	The system ensures that complete record integrity, including signature components, is maintained and cannot be tampered with and the Blockchain Ledger technology utilised provides further irrefutability. Access to signature records is read-only for system users (including system administrators). Procedures for Autolomous access to records of signatures are in place and will be reviewed as part of our ISMS.
Electronic signature issue
11.100 (a)	Each electronic signature is unique to one individual and shall not be reused by or reassigned to anyone else.	Electronic signatures utilise the unique user ID and passcode combination that is not reused or reassigned. It is the responsibility of the customer to ensure that policies are enforced to ensure that shared user IDs and passcode disclosure by users are not permitted. In addition, two-factor authentication (2FA) is enforced, which makes passcode sharing difficult and detectable.
11.100 (a)	No shared/group accounts are defined as electronic signatures.	Electronic signatures in AutoloMATE are for individuals only.
11.100 (b)	The identity of individuals must be verified prior to the use of an electronic signature	Users are required to resubmit their passcodes for each signature event.
11.100 (a)11.100 (b)11.100 (c)	An approved procedure which describes the administration of electronic signatures is available and includes:Issue of electronic signaturesWithdrawal of electronic signaturesLoss management proceduresA statement that electronic signatures are intended to be the legally binding equivalent of traditional handwritten signatures.	The system automatically enforces the application and recording of electronic signatures. It is the responsibility of the customer to write their own procedure for administration of electronic signatures within their environments and to ensure that those users using electronic signatures in each instance have the training and competence to do so.The customer should ensure that users understand the legal equivalence of electronic signatures with handwritten ones by means of policies, procedures and training.
Non-biometric signature use
11.200 (a)(1)	The electronic signature consists of two distinct identification components such as:User ID/Password combinationToken (e.g. swipe card)/password combination	A user ID and passcode combination is utilised for electronic signatures that are legally equivalent to manual signatures and are fully attributable to individual system users.
11.200 (a)(1) (i)	The first signing in a single period of controlled system access must use both signature components.	Each user login session requires two components (email and passphrase). Each electronic signature during a login session requires passcode confirmation.
11.200 (a)(1) (i)	Subsequent signings in the same session may use one component only.  This is an optional requirement but if used then the component must be the secure part i.e. the password.	Each electronic signature during a login session requires the secure component (passcode) confirmation. The system automatically validates user identity.
11.200 (a)(2)	The electronic signature must only be used by the genuine owner.	It is the responsibility of the customer to ensure that policies are enforced to ensure that users do not perform signatures under another user’s user name and that passcode disclosure by users is not permitted. System audit trails can be used to audit user compliance.
11.200 (a)(3)	Signatures must 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.	This is guaranteed by means of unique user accounts and passcodes and enforcement of the policy for non-disclosure of passcodes.
Controls for identification codes and passwords
11.300 (a)	Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.	This is guaranteed by means of unique user accounts and unique, system-generated passcodes.
11.300 (b)	Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).	This function is performed by the system administrator. It is the customer’s responsibility to enforce the control under suitable policies and procedures.
11.300 (c)	Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.	Autolomous software products do not make use of physical tokens or cards or other physical identity verification devices. If a customer chooses to add these to the security system, they must develop and validate them and take responsibility for their management. It is the customer’s responsibility to enforce the policy requirement that passphrases and passcodes are not written down.
11.300 (d)	Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.	Passphrases and passcodes are not displayed as readable characters when entered so they may not be copied by an onlooker.Customers are responsible for unauthorised use procedures.
11.300 (e)	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 and have not been altered in an unauthorized manner.	Autolomous software products do not make use of physical tokens or cards or other physical identity verification devices. If a customer chooses to add these to the security system, they must develop and validate them and take responsibility for their management. It is the customer’s responsibility to enforce the policy requirement that passphrases and passcodes are not written down.