Electronic Record Keeping Systems and Electronic Signatures

Effective Date: 14 February 2007

Version in Effect: 7 (revised 15 March 2022)

Reference: TAM Part 5, Chapter 5, Section 2

OPI / Telephone: DTAES 4-5 / 819-939-4757

1. Purpose

1.1. This TAA Advisory provides a method for compliance with the requirements of the Technical Airworthiness Manual (TAM) pertaining to Electronic Record Keeping Systems (ERKS) and Electronic Signatures.

1.2. This TAA Advisory is not mandatory, nor does it constitute a regulation. It describes a means acceptable to the TAA, but is not the only means to demonstrate compliance with the regulation(s). If you choose to use this TAA Advisory, all of its aspects of it must be followed.

2. Applicability

2.1. This TAA Advisory is applicable to all organizations seeking TAA acceptance of an ERKS that is the sole repository for some part, or all, of their Type or Technical records, as defined in TAM paragraphs 5.5.2.R1 and R2, as well as of the electronic signatures associated with the formal approval of each of these airworthiness-related documents.

2.2. In addition, this advisory has been generated to assist organizations in obtaining TAA acceptance for new ERKS or upgrades to existing systems. This advisory provides guidance on how the TAA will evaluate an ERKS to ensure compliance with the regulatory requirement stipulated under paragraph 3.2.1.

2.3. All of the requirements described in paragraph 4.5 are applicable to organizations seeking TAA Airworthiness Acceptance for the implementation of a new ERKS. For upgrades to existing ERKS, it is possible that not all of the elements listed in paragraph 4.5 are applicable. The TAA will assist organizations in defining the Project Plan deliverables, which may vary, depending on the complexity and extent of the upgrade. Organizations seeking approval for both new and upgraded ERKS will be required to submit a Project Plan to the TAA for formal review and acceptance.

3. Related Material

3.1. Definitions:

1. Electronic Record Keeping System (ERKS). A system of record processing in which technical and type records are entered, stored and retrieved electronically by a computer system rather than in the traditional hard copy form.
2. Electronic Signature. A unique digital identifier, traceable to an authorized person, which is used by the individual to authenticate, attest to and certify that entries made into a legal record are verifiable, complete and accurate.

3.2. Regulatory References:

3.2.1. C-05-005-001/AG-001 – Technical Airworthiness Manual (TAM):

1. Part 5, Chapter 5, Section 2 – Electronic Record Keeping Systems
2. Part 5, Chapter 3, Section 2 – Maintenance Program Requirements

3.2.2. TAA Advisory 2017-04 – Contract Requirements for Airworthiness-Related In-Service Support Services

3.2.3. Civil and/or other military airworthiness regulations/advisories:

1. FAA Advisory Circular (AC) 120-78A – Electronic Signatures, Electronic Recordkeeping, and Electronic Manuals
2. Transport Canada, Civil Aviation (TCCA) Canadian Aviation Regulation (CAR), Part VI, General Operating and Flight Rules, Subpart 5, Aircraft Requirements, Division IV, Technical Records 605.93, Technical Records – General
3. TCCA AC 521-101 – Electronic Record-Keeping System, Modeling Systems and Manuals

4. Discussion

4.1 A significant amount of airworthiness-related documentation is produced to provide the essential information and data necessary to establish and maintain the airworthiness of an aeronautical product. Much of this information and data must be retained indefinitely and be accessible at any point in time. Computers have been used for many years for the planning, analysis, scheduling and documentation associated with the production of this airworthiness-related information and data. However, paper records were more often than not the method used to provide the documentary evidence required by the TAA. This is particularly true for the required airworthiness certifications associated with engineering decisions or the completion of a maintenance task.

4.2 As organizations transition over to ERKS, they need to clearly understand the risks to their data. Common vulnerabilities of an ERKS of interest to the TAA include, without being limited to, the following:

1. Electronic records can easily be deleted without trace in most commercial applications;
2. Editing of electronic records is facilitated by features such as global search and automatic replace functions;
3. Correction of data entry errors often involves “data overwrite” capabilities; and
4. A secure electronic signature requires advanced technology and does not provide the physical evidence of a hand-written signature.

4.3 Organizations must prove to the satisfaction of the TAA that sufficient safeguards have been implemented to overcome the vulnerabilities of electronic records, and appropriate measures have been taken to ensure the integrity of the system and the airworthiness-related data contained within the system.

4.4 The technical airworthiness functions have been established within the Technical Airworthiness Program to enable an airworthiness certification to be performed upon the completion of an airworthiness-related task, when directed by a technical airworthiness rule or standard. This signature confirms that relevant airworthiness-related tasks have been carried out as required and that the individual signing for the airworthiness function is assuming responsibility for it. It recognizes previous actions accomplished by one or more individuals, and is a pre-requisite for further actions to be carried out subsequently by other individuals. TAM Part 5, Chapter 5 covers the rules and standards that regulate the generation and maintenance of airworthiness documentation, including the requirements for electronic record keeping systems (ERKS) and electronic signatures. In this context, the signature process, written or electronic, must meet the same requirements. These requirements are:

1. Identification. The signature must positively identify the signatory for the life of the document.
2. Uniqueness. The signature must identify the signatory such that the signatory cannot credibly deny the signature.
3. Protection. The signature process must ensure that the use of the signature is under the sole control of the signatory.
4. Accountability. The signature process must affix the signature to all applicable data and information such that the signatories are fully aware of what they are signing for, and are accountable for the validity and accuracy of that data and information.
5. Integrity. The signature process must maintain the integrity of the data and information, preventing or detecting alterations being made after signing of the original document. Any corrections or changes must be made in such a way that the original data will still be available.

4.5 Acceptable Means of Compliance. An organization seeking acceptance for an ERKS must meet the requirements of reference 3.2.1. and provide the TAA with the following:

4.5.1 Project plan. The organization must submit to the TAA, for acceptance, a plan covering the intended scope of a new ERKS, or of upgrades to an existing one, and describing how all of the applicable elements below will be accomplished.

4.5.2 Data Migration and Validation. This phase is often the most critical and complex step in implementing a new ERKS. Whether it involves the migration of data from an existing ERKS (paper-based, or electronic), or bringing in “as designed/as maintained” data from the Original Equipment Manufacturer for a new TAA type-certified aircraft, a complete data migration and validation plan needs to be developed and accepted by the TAA. Normally, the Project Plan provides a high-level description of the way in which the data migration and validation will occur, including milestones, schedule and deliverables. However, due to the complexity and level effort, the ERKS Project Plan will link to a stand-alone Data Migration and Validation Plan that is incorporated by reference, and forms part of the TAA acceptance of the covering ERKS Project Plan.

Notes:
1. The scope of data required for migration largely depends on the scope of functionality of the ERKS. For example, an enterprise ERKS (e.g., SAP), where the master data is centrally controlled, and materiel management, engineering support, and maintenance/maintenance control functions are built in, has far more complex data requirements than an ERKS that simply provides maintenance recording (Work Order management system). For new aircraft, the In-Service Support (ISS) contract requirements will have an ERKS data deliverable, as described in reference 3.2.2.
2. For upgrades to existing ERKS, the Data Migration and Validation Plan may not be required, if the upgrades do not impact the existing data.

4.5.3 Verification and validation (V and V) of system functionality. This phase will ensure that the ERKS can meet all of the airworthiness requirements stipulated in the TAM that the ERKS is intended to support. For example, if the ERKS provides functionality related to aircraft release certification, it would need to comply with TAM 3.1.2.R11. In addition, ERKS validation is required to support all requirements of reference 3.2.1. The organization must prove that sufficient system validation and verification testing was conducted to demonstrate that the defined system functionality provides the expected results. In general, a series of tests involving a range of possible scenarios are executed, with the results documented and assessed as satisfactory. The functionality targeted for verification and validation should include all functions deemed critical to the airworthiness-related information and data within the ERKS. The tests and scenarios used to demonstrate system integrity should reflect the way the system would be used within the applicable organizations (i.e., maintenance, engineering, etc.). Reports from this phase must cover what was tested, expected results, actual results, recommendations, modifications (if required) and re-testing (if required).

Notes:
1. When implementing new and unfamiliar ERKS, functionality testing is also an important step in identifying training requirements (see para 4.5.8), as well as the airworthiness and business processes, including the user’s guide (see paras 4.5.6 and 4.5.7), which will need to be in place prior to bringing the system into service. For example, if the functionality scope includes engineering activities associated with managing the ERKS master data (i.e., maintenance program and allowed structure/parts configuration changes), then the testing should ultimately identify the training and procedural requirements for performing these types of activities.
2. When upgrading an existing ERKS, the V and V only needs to address the new functionality (if applicable).

4.5.4 Parallel System Operation

4.5.4.1 Where the ERKS is used to capture critical data that supports airworthiness activities, a parallel record keeping system (PRKS) may be required during the ERKS start-up. Examples of critical systems would be a Health and Usage Monitoring System ( HUMS) and an electronic maintenance scheduling and forecasting functionality. Paper-based records are an acceptable parallel system. Where an organization uses an additional electronic system as their parallel system, they will need to ensure that the systems are operated separately, to avoid cross-contamination of the data collected. The parallel system and duration of parallel system operations must be defined in the Project Plan. This can also take the form of a separate stand-alone Parallel System Operations Plan that is referenced from the Project Plan. The goal of the PRKS is to operate until such time that the following objectives (exit criteria) are met:

1. The transition to the new ERKS (entrance criteria) has been successfully executed (see para 4.5.9);
2. All procedures identified in the Quality System Plan have been implemented (see paras 4.5.6 and 4.5.7);

Note: The Quality System Plan needs to identify all procedures required to support the ERKS in service, including configuration management activities, such as making changes to master data (allowed structure, maintenance planning requirements). This would also include procedures for the management and control of compliance data such as, Service Bulletins, Modifications, Deviations/Flight Permits, etc.

3. The ERKS is accurately tracking and forecasting all scheduled maintenance program requirements defined in the approved program master maintenance planning document (i.e., derived from Airworthiness Limitations/Certified Maintenance Requirements and Scheduled Maintenance Requirements (chapters 4 and 5 of the Aircraft Maintenance Manual, respectively), and in the approved maintenance publications, including any additional technical airworthiness requirements, in accordance with reference 3.2.1.b;
4. A means of auditing the scheduled maintenance requirement against a master maintenance planning document has been developed and proceduralized (para 4.5.5.i);
5. A continuous improvement system is in place to address issues caused by human error and/or deficiencies in the ERKS; and
6. A consensus has be gained that the users of the ERKS are confident in using the system, and any deficiency has been corrected through training (para 4.5.8).

4.5.4.2 The PRKS plan should have a means to collect supporting evidence on how each exit criteria have been met, which can be submitted with a formal request to the TAA to cease the PRKS.

Note: In cases where an organization is implementing an ERKS that is already in use for other fleets, and has previously been accepted by the TAA, the PRKS is not normally required. The project transition plan (para 4.5.9) will describe the entrance criteria for “go-live” using the new system, as well as any post-“go-live” activities that will have to be executed and satisfied (see exit criteria in para 4.5.4 above) prior to achieving full TAA Airworthiness Acceptance of the ERKS.

4.5.5 ERKS Management Plan. Data management involves the implementation of system safeguards and measures to prevent the loss during the storage, processing and transmission of information and data. In addition, data management involves the activities associated with updating, accessing and validating data records. A Data Management Plan, at a minimum, shall cover:

1. Back-up procedures that ensure easy recovery of data in case of inadvertent loss or destruction of data. Backed-up data should be stored on a different server or medium than the primary data. In addition, the backed-up data medium should be in a different location. Data back-ups should be done on a regular basis;
2. System Disaster Response procedures, to deal with all likely system failures, power shortages or data loss. The procedures should define how any lost data would be identified and recovered. One method that may be used within the disaster response procedures is for the organization to temporarily revert to paper records to minimise the impact on operations;

Note: Normally, the Back-up and Disaster Response requirements, including a means to continue operating with the system down, are developed to meet the requirements of the Type Certificate Holder (TCH)’s Business Continuity Plan.

3. System Access procedures, to ensure that access is controlled in order to protect the information and data retained within the ERKS against tampering, whether accidental or intentional. An organization should define how the access control system will be implemented for each terminal used to enter or process data. If passwords are used, adequate procedures should be in place to protect and regularly change user passwords;
4. Data Transfer procedures, to cover how data transfer is accomplished, the hardware used and the method of confirming that the data recorded by the server is accurate and complete. V and V of the data transfer functionality (para 4.5.3) needs to be captured in the test plan and, where the user has a role to play during the data transfer process, one or several data transfer procedure(s) will be required. The following are examples of data transfer processes where additional procedures are required:
   1. HUMS – transfers of usage data and Fault Codes (also known as Event Codes) that are present following a flight. Normally, the usage data flows into the ERKS and auto-updates the maintenance schedule forecasting record. However, there is typically a debrief process for fault codes, to determine which ones are “nuisance codes”, versus system failure codes that must be accepted and allowed to pass into the ERKS for the auto-generation of a Work Order. The debrief process will need to be proceduralized.
   2. ERKS Master Data – For enterprise systems, master data (i.e., allowed parts, maintenance planning configuration, etc.) is often pushed into the ERKS by an approved Logistics Support Analysis Record (LSAR), which is maintained by an Acceptable Design Organization (ADO). Prior to accepting the data into the ERKS Master Data Tables, there is a comprehensive review by the TCH ERKS Central Data Mangers (CDM) to verify data accuracy, as well as the impact of the change to the operator. This activity will always require one or several detailed procedure(s).
5. System Configuration change procedures, to ensure that all ERKS changes are documented and auditable. Configuration changes can result from ERKS software changes, to address user-requested changes and continuous improvement upgrades (ERKS design changes), baseline data changes (i.e., master data) and dynamic data changes (i.e., maintenance transactions). Each change type will trigger a unique system verification procedure required before the release of the change. In addition, the ERKS should be capable of logging each type of change, including the individual who made the change, to any baseline data. System configuration changes can only be performed by authorized personnel within the organization or the organization’s approved support network;

Note: Depending on the scope of the ERKS, configuration change management test scenarios should be included as part of V and V (para 4.5.3). For changes that are actually correcting errors in historical records, the data correction procedure at paragraph 4.5.5.g will apply.

6. Data Access procedures, to cover how data within the ERKS is provided as information to the organization. This would include summary configuration reports for the entire aircraft fleet and the ability to print appropriate reports on demand. For example, if an ERKS is used to manage aircraft maintenance records, the ERKS must be able to produce hard copy reports that meet the technical record requirements of TAM 5.5.2.R2. ERKS features should allow the user to tailor the report to specific information and/or date range, which would ensure that the equipment being sent for third level repair and overhaul will have access to the relevant component history;
7. Data Correction procedures, to ensure access to the original data after a correction has been made to electronic data. A link between the original record and the corrected record must exist in order to provide the required data traceability. In addition, substantiating information that includes the date of alteration, the reason for the alteration, and the person’s name and signature or employee identifier is required;

Note: For modern ERKS, there is normally a logging functionality that records all transactions that occur in the system. This is normally an acceptable means of tracking data correction events.

8. Electronic Signature procedures, when an electronic signature is used within the ERKS, must meet the requirements of paragraph 4.8 of this advisory; and
9. Audit procedures should cover how ERKS data is audited in service, and are required to ensure that the ERKS is accurately tracking all required tasks. This is a critical activity, since all systems will, from time to time, display erroneous information, whether it is caused by a software deficiency or a user error. An organization using the ERKS must take steps to minimize the likelihood that system errors will impact airworthiness-related activities. As a minimum, the auditing process should cover:
   1. Confirmation that all maintenance requirements all configured in the ERKS, by validating the data against a master (independent) maintenance planning document. Validation should include the following:
      1. All inspections are tracking against correct measurement point in structure,
      2. Frequencies are correctly set for all tracking indices (i.e., AFHs, Landings, Cycles, Calendar Time, etc.) and, for inspections tracked against components, these frequencies are applicable to the specific component configuration (i.e., Part Number),
      3. Inspections are running and tracking properly (i.e., counting down as usage is incurred),
      4. Inspection due dates (i.e., since last inspection, overhaul and/or retirement limit) and tolerance windows are correct, and
      5. All installed parts are correct, including alternate parts, when compared to the maintenance planning document;
   2. A just-in-time (e.g., daily, weekly, etc.) confirmation that any transaction that impacts the aircraft configuration, affecting the maintenance planning document, has been completed correctly;
   3. A flexible/efficient frequency of audit schedule that is based on error rate, airworthiness risk, and event based scenarios (e.g., after heavy maintenance, aircraft transfer, etc.);
   4. A means of documenting audit events and findings, including addressing findings (i.e., observations, corrective actions, continuous improvement) within the quality system;

4.5.6 System User Guides. The organization implementing the ERKS must develop user guides that describe how the ERKS system functionality is used and how the system is maintained. The user documentation will include basic user instructions and advanced system management instructions.

Note: Fit-for-purpose commercial off-the-shelf (COTS) ERKS will normally come with a built-in user guide. However, homegrown ERKS or COTS ERKS that have been highly tailored to address unique organizational requirements will require the development of a user guide, or user guide supplement.

4.5.7 Quality System Plan. The organization implementing the ERKS must update all airworthiness policies and enabling procedures that involve the use of the ERKS. A Quality System Plan can be described within the Project Plan. However, it is more often referenced from the Project Plan as a stand-alone document. It is recognized that some procedures may not have an airworthiness impact and will be developed post-“go-live”, as more experience is gained with the ERKS. However, the Quality System Plan will need to identify the critical procedure that will need to be developed for “go-live”, versus those that will be developed within a defined schedule, post-“go-live”. TAA acceptance of the Project Plan includes any quality plan incorporated by reference. The TAA will monitor the execution of the Quality System Plan through to completion during the ERKS provisional airworthiness acceptance period. Accredited organizations will require TAA approval of all changes to their Airworthiness Process Manuals.

4.5.8 Training Plan. The organization implementing the ERKS must develop a Training Plan that ensures initial training is provided to all ERKS users and, where required, recurrent training is provided. The scope of the training must match the complexity of the user requirements. It would be expected that ERKS administrators have the necessary skills, knowledge and experience to perform all ERKS management activities, and would receive application-specific training, as required. All training must be carried out as close to commencement of ERKS use as possible, and the plan should include a contingency, in the event that the implementation is delayed.

4.5.9 Transition Plan. During the stand-up period of the ERKS, the organization will be managing all legacy processes, developing new processes, conducting training and updating “as maintained data” within the ERKS (i.e., data that captures all of the changes that occurred from the point in time when the data was initially loaded into the ERKS, to the actual status of the aircraft at "go-live"). For a complex ERKS, the organization will need to develop a Transition Plan that describes how all of these activities will be managed, including an entrance criteria assessment, which provides a gate for commencing use of the new system as the primary ERKS. While the organization is transitioning, it must ensure that an appropriate level of additional user support is available during the implementation period.

4.5.10 Technical Data Package. The organization seeking TAA acceptance of the ERKS must develop, maintain and manage the configuration of all documentation supporting the requirements described above.

4.6 TAA Project Plan Acceptance. The TAA will review the Project Plan and provide feedback to the organization. For a complex ERKS, there will be a number of milestones negotiated between the organization and the TAA, which may require an on-site audit or a review of supporting documentation (see para 4.5.10). The milestones and documentation requirements will be defined in the TAA Project Plan Acceptance Letter. This will allow for the TAA Airworthiness Acceptance of the ERKS to be based on a Project Plan executed by the organization over an extended period of time.

4.7 TAA Airworthiness Acceptance (for "go-live"). Once the TAA is satisfied that the ERKS is ready for implementation, based on the final Technical Data Package, the organization will be given the authority to start interim operations, in accordance with the Transition Plan (provisional acceptance). Prior to this occurring, the organization must submit a letter from the SMM and/or SDE certifying that the ERKS meets all airworthiness requirements, and that all required training, procedures and instructions have been instituted. Depending on the complexity of the ERKS, the TAA may conduct an on-site audit and evaluate the ERKS against all airworthiness requirements. Full TAA Airworthiness Acceptance of the ERKS will occur once the Project Plan activities have been completed, including those activities that were planned for after “go-live” (i.e., quality system updates, audit procedures, etc.).

4.8 Electronic Signatures. An organization seeking acceptance for the use of Electronic Signatures within an ERKS must meet the requirements of paragraph 4.4 and satisfy the TAA that the following have been met:

1. Identification. An identification number, a coded magnetic card, a thumb/finger print, an eye print or similar concepts can be used to identify the signatory.
2. Uniqueness. An acceptable method of proving uniqueness of a signature is by using an authentication procedure that, in combination with the identification procedure, validates the identity of the signatory. Acceptable means of identification and authentication includes the use of separate and unrelated identification and authentication codes. A combination of a Personal Identification Number (PIN) and coded magnetic card, a thumb/finger print, a retina scan or similar concepts can be used to authenticate the identity of the signatory accurately and positively.
3. Protection. The satisfaction of identification and uniqueness outlined above plus positive control over the process of issuing and use of identification and authentication codes can ensure that an acceptable electronic signature would be under the direct control of the signatory.
4. Accountability. The accountability for the validity and accuracy of the information can be accomplished by ensuring that the system links the signature to all the information, and only the information, relevant to the specific airworthiness function being affirmed by that signature and identifies to the signatory all information or actions that are being signed for.
5. Integrity. A date/time stamp should be incorporated into the electronic document at the time of the original electronic signature, and thereafter at every alteration of the document.

4.9 The organization seeking TAA acceptance of Electronic Signatures will need to provide the TAA staff with the required Airworthiness Process Manual and procedure content that detail:

1. The means used to manage and control each physical item provided to support the signature process;
2. The means used to manage and control the assignment of identification codes to support the signature process;
3. Instructions for data management that ensure the integrity of information, allowing all data changes to be traced to the author of the change;
4. Instructions for data management that ensure the integrity of information, ensuring that original data that has been subjected to a change process is still retrievable in its original unchanged form;
5. Instructions that allow for data to be retrieved as a complete set of information so that all data associated with a single signature are known; and
6. Policy that covers the organizations acceptance of the electronic signature and the airworthiness documentation where electronic signatures are deemed acceptable.

4.10 An organization seeking TAA acceptance of Electronic Signatures should consult with TAA staff prior to initiating a project involving the transition from hand written signatures/stamps to electronic signatures.